From: Alex Williamson <alex.williamson@redhat.com>
To: bk rakesh <rakeshbkrish@gmail.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
jiang.liu@linux.intel.com
Subject: Re: Hardware support for vt-posted interrupts described in vt-directed-io-spec for assigned devices
Date: Fri, 20 Mar 2015 08:04:51 -0600 [thread overview]
Message-ID: <1426860291.3643.471.camel@redhat.com> (raw)
In-Reply-To: <CABxdwOwZGyi6d+AFGhEE8+LBN6Pc2CvqRm1TEHCB-foYWUK6=A@mail.gmail.com>
On Fri, 2015-03-20 at 15:24 +0530, bk rakesh wrote:
> Adding few more information regarding the setup which i had created to
> test the vt-d posted interrupts for assigned devices,
>
> Hardware used for evaluating vt-posted interrupts
> cpu "E5-2620 v2 @ 2.10GHz" and "S2600CP server board"
>
> I had used kernel-3.18 patched with "KVM-VFIO IRQ forward
> control(posted by eric.auger@linaro.org)",
IRQ forwarding in an ARM technology for handling level triggered
interrupts, not Intel, not even x86.
> "hierarchy irqdomian(posted
> by jiang.liu@linux.intel.com)" and "VT-d Posted-Interrupts
> support(http://lwn.net/Articles/626050/) and assigned the ixgbe 10G
> NIC via vfio passthrough using qemu-kvm, But resulted in the following
> dmesg output,
>
> [233783.657187] dmar: DRHD: handling fault status reg 602
> [233783.662926] dmar: INTR-REMAP: Request device [[02:00.0] fault index 47
> INTR-REMAP:[fault reason 36] Detected reserved fields in the IRTE entry
This suggests bugs in the patch series for setting bits that are
reserved on the hardware in your test system.
> I had checked the hardware supported for posted interrupt capability
> via capability register bit 59 (#define cap_pi_support(c) (((c) >>
> 59) & 1)), as described in
> "http://www.intel.com/content/www/us/en/embedded/technology/virtualization/vt-directed-io-spec.html",
> Which resulted as not supported, Can anyone suggest that does this hw
> support posted vt-d feature ?
Your own hardware is telling you that it doesn't support it.
> if not then which one to use.
Personally I would have no expectation that any currently shipping
hardware supports this feature. If you watch one of GregKH's talks on
how the Linux community works or follow development for a while, you'll
see and hear that Intel will often pre-enable features before the
hardware that supports it is available. I suspect this is one of those
features. Thanks,
Alex
next prev parent reply other threads:[~2015-03-20 14:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 7:19 Hardware support for vt-posted interrupts described in vt-directed-io-spec for assigned devices bk rakesh
2015-03-20 9:54 ` bk rakesh
2015-03-20 14:04 ` Alex Williamson [this message]
2015-03-20 14:10 ` Eric Auger
2015-03-20 14:21 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1426860291.3643.471.camel@redhat.com \
--to=alex.williamson@redhat.com \
--cc=jiang.liu@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rakeshbkrish@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.