From: Qing He <qing.he@intel.com>
To: Shohei Fujiwara <fujiwara-sxa@necst.nec.co.jp>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH 0/6] MSI-INTx interrupt translation for HVM
Date: Thu, 15 Jan 2009 14:25:14 +0800 [thread overview]
Message-ID: <20090115062514.GC25230@ub-qhe2> (raw)
In-Reply-To: <20090115113132.2D51.CB716985@necst.nec.co.jp>
On Thu, 2009-01-15 at 10:35 +0800, Shohei Fujiwara wrote:
> I think MSI-INTx translation can be enhanced.
>
> In case of using MSI enable bit as mask, guest OS need to set interrupt
> disable bit to prevent device from asserting INTx. Actually, linux
> 2.6.25 set interrupt disable bit in
> drivers/pci/msi.c:msi_capability_init. If interrupt disable bit is 1,
> we can assume guest OS might use MSI enable bit as mask. If interrupt
> disable bit is 0 and MSI enable bit is 0, we can assume guest OS uses
> INTx.
This should be better, but cannot garauntee it. Since INTx disable bit
was added in PCI 2.3. Early guests may exist not using it. Also, some
devices have problems, that setting INTx disable bit also completely
disables MSI from signalling, so OS may not touch INTx disable bit of
these devices.
Theoretically, MSI-enable-as-masking is not correct and should not be
used in the first place. If that were true it would be much easier for
us. However, the existing (and widely used) guest complicates this matter...
>
> I think we can archive both of good performance and not-using INTx, if
> we control MSI-INTx translation as follows.
>
> MSI/MSI-X | Interrupt | MSI-INTx | Note
> enable bit | disable bit | translation |
> -----------+-------------+-------------+------------------------------
> 0 | 0 | enable | Re-enabling MSI-INTx
> | | | translation is needed.
> -----------+-------------+-------------+------------------------------
> 0 | 1 | disable | Guest OS might use MSI enable
> | | | bit as mask.
> -----------+-------------+-------------+------------------------------
> 1 | 0 | disable | Guest OS use MSI/MSI-X.
> -----------+-------------+-------------+------------------------------
> 1 | 1 | disable | Guest OS use MSI/MSI-X.
>
> It is great if we can guarantee INTx interrupt isn't used.
> We don't need to consider sharing machine gsi. We don't need to consider
> hot-pluging I/O APIC. In long term, It will be possible even to to remove
> I/O APIC from real machine.
I am not against it, it does look more symmetric, though in the cost of
a little overhead (4 hypercalls for a mask operation) in the worst
(but rare) case. I'll ack the patch if you add it now, or you can wait
for me to add it at some later time.
Thanks,
Qing
>
> What do you think?
>
> Thanks
> --
> Shohei Fujiwara
>
next prev parent reply other threads:[~2009-01-15 6:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-08 9:06 [PATCH 0/6] MSI-INTx interrupt translation for HVM Qing He
2009-01-08 9:06 ` [PATCH 1/6] passthrough: MSI-INTx " Qing He
2009-01-08 9:06 ` [PATCH 2/6] ioemu:passthrough: MSI-INTx interrupt translation support Qing He
2009-01-08 9:06 ` [PATCH 3/6] pci: add pci option support for XML-RPC server Qing He
2009-01-08 9:06 ` [PATCH 4/6] pci: add pci option support for XenAPI server Qing He
2009-01-08 9:06 ` [PATCH 5/6] pci: add config options for MSI-INTx translation in HVM Qing He
2009-01-08 9:06 ` [PATCH 6/6] passthough: MSI-INTx translation documentation Qing He
2009-01-08 10:44 ` [PATCH 0/6] MSI-INTx interrupt translation for HVM Shohei Fujiwara
2009-01-08 14:52 ` Qing He
2009-01-09 4:26 ` Shohei Fujiwara
2009-01-09 6:57 ` Qing He
2009-01-13 9:05 ` Shohei Fujiwara
2009-01-13 9:28 ` Qing He
2009-01-14 6:39 ` Shohei Fujiwara
2009-01-14 7:38 ` Qing He
2009-01-14 8:26 ` Shohei Fujiwara
2009-01-14 9:17 ` Qing He
2009-01-15 2:35 ` Shohei Fujiwara
2009-01-15 6:25 ` Qing He [this message]
2009-01-16 4:34 ` Shohei Fujiwara
2009-02-27 2:41 ` Shohei Fujiwara
2009-03-01 14:55 ` Keir Fraser
2009-03-02 7:19 ` Shohei Fujiwara
2009-03-02 8:47 ` Keir Fraser
2009-03-02 9:24 ` Qing He
2009-03-02 9:40 ` Keir Fraser
2009-03-02 10:27 ` Shohei Fujiwara
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=20090115062514.GC25230@ub-qhe2 \
--to=qing.he@intel.com \
--cc=fujiwara-sxa@necst.nec.co.jp \
--cc=xen-devel@lists.xensource.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.