All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 13 Jan 2009 17:28:13 +0800	[thread overview]
Message-ID: <20090113092813.GA9499@ub-qhe2> (raw)
In-Reply-To: <20090113175932.EA8A.CB716985@necst.nec.co.jp>

On Tue, 2009-01-13 at 17:05 +0800, Shohei Fujiwara wrote:
> What I understand are the followings.
> 
>     - When guest gsi isn't shared, MSI-INTx interrupt translation works fine.
>     - When guest gsi is shared between passthrough device and emulated
>       device, MSI-INTx interrupt translation work, though guest OS
>       receives spurious interrupts.
>     - Sharing guest gsi among passthrough devices isn't supported.

Yes.

>     - There are some unsuitable devices for MSI-INTx interrupt translation.

I still don't know an example of such unsuitable devices. And to be
exact, it should be device/guest OS driver combination. The improper
function may be caused by the guest driver (e.g. not cleaning irq source
before issuing EOI)

> 
> 
> May I ask you any additional questions?
> 
> First, why can't we assign more than 8 devices?
> In the view of guest OS, assigned device is always single function
> device. This means assigned devices use only INTA. And Interrupt
> routing in hypervisor is shown as follows.

Well, I just checked the code, seems I'm using the stale knowledge.
The assigned devices didn't fix to INTA a few months ago, at that time,
it was 8, since (0:3.1) collided with (0:11.0).

It's now 32, and the situation is definitely much better.

> 
> From xen/include/asm-x86/hvm/irq.c:
>     #define hvm_pci_intx_gsi(dev, intx)  \
>         (((((dev)<<2) + ((dev)>>3) + (intx)) & 31) + 16)
> 
> I think sharing guest gsi among passthrough devices doesn't
> occur if assigned device is <= 32.
> 
> 
> Second, it is nice to create blacklist of unsuitable devices for MSI-INTx
> interrupt, isn't it? The reason is the problem seems device-specific problem.

This is reasonable, however, I don't know a real unsuitable at this
time. Isn't it better to add the blacklist when there is the real need?

What do you think?

Thanks,
Qing

> 
> Thanks,
> --
> Shohei Fujiwara
> 
> 

  reply	other threads:[~2009-01-13  9:28 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 [this message]
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
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=20090113092813.GA9499@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.