All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: James Sullivan <sullivan.james.f@gmail.com>,
	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 14:00:16 +0100	[thread overview]
Message-ID: <20150319130015.GA16070@potion.brq.redhat.com> (raw)
In-Reply-To: <20150319010932.GA18338@amt.cnet>

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.)

https://software.intel.com/en-us/forums/topic/288883
said that DM=1+RH=0 delivers to physical:

  The exact quote from 10.11.1 is "When RH is 0, the interrupt is
  directed to the processor listed in the Destination ID field."
  This does not specify if physical or logical addressing mode is used.

  Experimentation shows that physical addressing mode is used
  with RH equal to zero.

and it also mentioned a disturbing behavior, which I chose to ignore:

  10.11.1 goes on to say that "When RH is 1 and the physical destination
  mode is used [i.e., DM = 0], the Destination ID field must not be set
  to 0xFF; it must point to a processor that is present and enabled to
  receive the interrupt."

  This would seem to be the exact same case as RH equal to zero;
  there, DM is ignored: "If RH is 0, then the DM bit is
  ignored and the message is sent ahead independent of whether
  the physical or logical destination mode is used."

  However, changing RH to 1 and DM to zero fails to send the message
  to the physical processor.

  reply	other threads:[~2015-03-19 13:00 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ář [this message]
2015-03-19 22:51         ` James Sullivan
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=20150319130015.GA16070@potion.brq.redhat.com \
    --to=rkrcmar@redhat.com \
    --cc=gleb@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=sullivan.james.f@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.