From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Rolu <rolu@roce.org>
Cc: Deep Debroy <ddebroy@gmail.com>, xen-devel@lists.xen.org
Subject: Re: MSI message data register configuration in Xen guests
Date: Thu, 28 Jun 2012 16:52:03 -0400 [thread overview]
Message-ID: <20120628205203.GA25097@phenom.dumpdata.com> (raw)
In-Reply-To: <CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
On Tue, Jun 26, 2012 at 04:51:29AM +0200, Rolu wrote:
> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
> > Hi, I was playing around with a MSI capable virtual device (so far
> > submitted as patches only) in the upstream qemu tree but having
> > trouble getting it to work on a Xen hvm guest. The device happens to
> > be a QEMU implementation of VMWare's pvscsi controller. The device
> > works fine in a Xen guest when I switch the device's code to force
> > usage of legacy interrupts with upstream QEMU. With MSI based
> > interrupts, the device works fine on a KVM guest but as stated before,
> > not on a Xen guest. After digging a bit, it appears, the reason for
> > the failure in Xen guests is that the MSI data register in the Xen
> > guest ends up with a value of 4300 where the Deliver Mode value of 3
> > happens to be reserved (per spec) and therefore illegal. The
> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
> > illegal (per expectation) causing all commands issued by the guest OS
> > on the device to timeout.
> >
> > Given this above scenario, I was wondering if anyone can shed some
> > light on how to debug this further for Xen. Something I would
> > specifically like to know is where the MSI data register configuration
> > actually happens. Is it done by some code specific to Xen and within
> > the Xen codebase or it all done within QEMU?
> >
>
> This seems like the same issue I ran into, though in my case it is
> with passed through physical devices. See
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
> the older messages in that thread for more info on what's going on. No
> fix yet but help debugging is very welcome.
Huh? You said in http://lists.xen.org/archives/html/xen-devel/2012-06/msg01653.html
"This worked!"
next prev parent reply other threads:[~2012-06-28 20:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-26 2:38 MSI message data register configuration in Xen guests Deep Debroy
2012-06-26 2:51 ` Rolu
2012-06-27 23:18 ` Deep Debroy
2012-06-28 20:52 ` Deep Debroy
2012-06-29 11:10 ` Stefano Stabellini
2012-07-03 5:54 ` Deep Debroy
2012-07-03 10:20 ` Stefano Stabellini
2012-07-03 10:28 ` [PATCH] xen: event channel remapping for emulated MSIs Stefano Stabellini
2012-06-28 20:52 ` Konrad Rzeszutek Wilk [this message]
2012-06-28 21:26 ` MSI message data register configuration in Xen guests Deep Debroy
2012-06-28 21:27 ` Rolu
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=20120628205203.GA25097@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=ddebroy@gmail.com \
--cc=rolu@roce.org \
--cc=xen-devel@lists.xen.org \
/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.