From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH 0/3] xen: msi support for Xen dom0 Date: Tue, 18 Aug 2009 13:24:26 -0700 Message-ID: <4A8B0DFA.1020002@goop.org> References: <> <1250574314-19600-1-git-send-email-qing.he@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1250574314-19600-1-git-send-email-qing.he@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Qing He Cc: xen-devel@lists.xensource.com, yunhong.jiang@intel.com List-Id: xen-devel@lists.xenproject.org On 08/17/09 22:45, Qing He wrote: > This patch set adds support for msi in Xen dom0. It's based on the > pci notifier patches of Weidong Han (on rebase/pci branch) and > contains the following 3 patches. > > [PATCH 1/3] xen: make pci notifier work with booting devices > [PATCH 2/3] xen: add msi support for dom0 > [PATCH 3/3] xen: re-enable msi (effectively revert bf89bc29) > Thanks, I've applied these to rebase/dom0/msi for now. I haven't tested them (or really compiled them) yet, so please look at the branch and see that everything's OK. > One of the problem left is how to save/restore MSI across S3. Since > pci_restore_msi_state() now doesn't have any arch specific hook, the > code in arch/x86/ won't get a chance to run during S3 wakeup, so > write_msi_msg() is called instead of xen specific functions. One of > the possible solutions (and which I prefer) is to add something like > arch_pci_restore_msi, but that involves slightly changing > drivers/pci/msi.c, which probably needs more thinking and discussion. > > An alternative is to trap and emulate any access to pci configuration > space. In that case, nothing in dom0 needs changing, and write_msi_msg > can be reused, but considerable logic may need to change in Xen > hypervisor. > The approach taken by 2/3 is not really going to fly upstream, and is broadly incompatible with my intended design for interrupt handling, which is to decouple the Xen/dom0 aspects of interrupt handling from the apic/ioapic code entirely. I don't know what impact this will have on MSI support. I'd appreciate it if you could look at the rebase/dom0/new-interrupt-routing branch and comment on it. I'm not actually sure this approach is going to work; so far it just locks up the machine shortly after ACPI initialization. Trapping an emulating (IO-)APIC accesses may well turn out to be simpler (on the Linux side, at least) and more robust in the end... J