All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Sullivan <sullivan.james.f@gmail.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>,
	"Marcelo Tosatti" <mtosatti@redhat.com>
Cc: kvm@vger.kernel.org, gleb@kernel.org, pbonzini@redhat.com
Subject: Re: [Patch v5] x86: irq_comm: Add check for RH bit in kvm_set_msi_irq
Date: Thu, 19 Mar 2015 16:51:53 -0600	[thread overview]
Message-ID: <550B5309.1090805@gmail.com> (raw)
In-Reply-To: <20150319130015.GA16070@potion.brq.redhat.com>

On 03/19/2015 07:00 AM, Radim Krčmář wrote:
> 2015-03-18 22:09-0300, Marcelo Tosatti:
>>>> See native_compose_msi_msg:
>>>>                 ((apic->irq_dest_mode == 0) ?
>>>>                         MSI_ADDR_DEST_MODE_PHYSICAL :
>>>>                         MSI_ADDR_DEST_MODE_LOGICAL) |
>>>>                 ((apic->irq_delivery_mode != dest_LowestPrio) ?
>>>>                         MSI_ADDR_REDIRECTION_CPU :
>>>>                         MSI_ADDR_REDIRECTION_LOWPRI) |
>>>> So it does configure DM = MSI_ADDR_DEST_MODE_LOGICAL
>>>> and RH = MSI_ADDR_REDIRECTION_LOWPRI.
>>> ...and yet this is a good counterexample against my argument :)
> 
> (It could be just to make the code nicer ... the developer might have
>  known how real hardware will handle it.)
> 
>>> What I think I'll do is revert this particular change so that dest_mode is
>>> set independently of RH. While I'm not entirely convinced that this is the
>>> intended interpretation, I do think that consistency with the existing logic
>>> is probably desirable for the time being. If I can get closure on the matter
>>> I'll re-submit that change, but for the time being I will undo it.
>> Just write MSI-X table entries on real hardware (say: modify
>> native_compose_msi_msg or MSI-X equivalent), with all RH/DM
>> combinations, and see what behaviour is
>> comes up?  
> 
> I second this idea.
> (We'd also get to know how RH interacts with delivery mode.)
> 

I played around with native_compose_msi_msg and discovered the following:

* dm=0, rh=0 => Physical Destination Mode
* dm=0, rh=1 => Failed delivery
* dm=1, rh=0 => Logical Destination Mode, No Redirection
* dm=1, rh=1 => Logical Destination Mode, Redirection

So it seems to be the case that logical destination mode is used whenever
DM=1, regardless of RH. Furthermore, the case where DM=0 and RH=1 is
undefined, as was indicated in the closing response to the thread in
https://software.intel.com/en-us/forums/topic/288883 :

"...X86 supports logical mode but does not support redirection of physical mode
interrupts. I think they should have just said RH=1 is not defined in physical
mode, but instead they are trying to tell you what the restrictions are if you
set it on."

The default config for PCI devices seems to be DM=1,RH=1.

-James

  reply	other threads:[~2015-03-19 22:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-13 15:14 [Patch v5] x86: irq_comm: Add check for RH bit in kvm_set_msi_irq James Sullivan
2015-03-13 15:48 ` Radim Krčmář
2015-03-17 15:23 ` James Sullivan
2015-03-18 22:52 ` Marcelo Tosatti
2015-03-19  0:59   ` James Sullivan
2015-03-19  1:09     ` Marcelo Tosatti
2015-03-19 13:00       ` Radim Krčmář
2015-03-19 22:51         ` James Sullivan [this message]
2015-03-20 15:15           ` Radim Krčmář
2015-03-20 15:22             ` James Sullivan
2015-03-20 17:50               ` James Sullivan
2015-03-23 21:13                 ` Radim Krčmář
2015-03-23 22:46                   ` James Sullivan
2015-03-24 14:03                     ` Radim Krčmář
2015-03-24 14:17                       ` James Sullivan
2015-04-02 22:08                       ` James Sullivan
2015-04-03 10:11                         ` Radim Krčmář
2015-04-21 12:18           ` Paolo Bonzini
2015-04-21 12:44             ` Radim Krčmář
2015-03-19  1:11     ` Marcelo Tosatti

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=550B5309.1090805@gmail.com \
    --to=sullivan.james.f@gmail.com \
    --cc=gleb@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.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.