WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] The saga of Heterodyne's PCI Passthrough

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] The saga of Heterodyne's PCI Passthrough
From: "Drake Wilson" <drake@xxxxxxxxxxxxxx>
Date: Fri, 23 Sep 2011 00:25:32 -0500
Delivery-date: Thu, 22 Sep 2011 22:26:25 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:references:subject :in-reply-to:date; s=smtpout; bh=pmfzCCASYvHQeTWb+z7KVTDnPXo=; b= ipymk1gHAlbjk71lPp9wS/wePlzNFieXHEBWsIB3jfsLa6VVBa26Jc5qy4CLtyvA YOndSMzmUKBPrHE0UOjdZsMMM132GvxY7muHV/b7I47donZVj3Ppm5bnI7zliJvB IpNf70CAaiAHdUT42LLIbVRc7ifhfBRwr0uTAiJvQ/Q=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1316716679.25235.140258146613405@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <1316716679.25235.140258146613405@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
[...]

Hmm.  Loopiness follows.

So I finally chased down somewhere on the Web saying that MSI delivery modes
are similar to IPI delivery modes, and then I found the IPI types in the AMD64
architecture manual.  Apparently mode 3 is a remote read from a separate local
APIC.  This sounds totally bogus for an interrupt coming from a graphics card,
but I don't know for sure.

But after poring over the dmesg a bit more I realized a bunch of lower
interrupts were being eaten by PnP devices.  I suppose these are attached to
things like the emulated PS/2 keyboard.  Since I don't need those (I use the
serial device as emergency maintenance port), pnpacpi=off pnpbios=off in the
domU kernel, and magically there's enough interrupts to pass through both the
Radeon and the USB controller, or so it seems.

So that may be a good enough workaround for now.  But I still want to know why
those MSIs are apparently not being passed through.

Also apparently the interrupt limit is an architectural one, which I should
have known since it was hardcoded, but somewhere in there I made a logic error
I suppose (keeping in mind that I really don't know what I'm doing here).

Some primitive attempts to trace back where in the world mode 3 is coming from
yielded not much except for a twisty maze that points either into the guest OS
or maybe into some sort of structure corruption in the device model, maybe;
the only places that I could find where a Linux write_msi happens that would
alter the MSI Message Data register that way (as opposed to setting it to
hardcoded elements) are related to IOMMU stuff, such as io_apic.c:3051, and
some further primitive attempts to probe this yielded nothing useful.

I do notice that Linux xen_hvm_setup_msi_irqs doesn't seem to get called
anywhere, or at least its printk lines don't show up in dmesg, but whether
this is relevant I cannot say.

Kyaieee!

   ---> Drake Wilson

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>