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>
Cc: Marcelo Tosatti <mtosatti@redhat.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: Fri, 20 Mar 2015 09:22:11 -0600	[thread overview]
Message-ID: <550C3B23.30401@gmail.com> (raw)
In-Reply-To: <20150320151534.GB14772@potion.brq.redhat.com>

On 03/20/2015 09:15 AM, Radim Krčmář wrote:
> 2015-03-19 16:51-0600, James Sullivan:
>> 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
> 
> Great!  (What CPU family was that?)
> 

This was on Intel x86_64 (Core i5-3210m, 'Ivy Bridge').

>> 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 :
> 
> DM=0+RH=1 might be defined to "fail", but I think it's acceptable to
> treat it as undefined.  (Deliver them in KVM if it improves something.)
> 

My thoughts as well.

> I'm still wondering about last sentence from that link, the
> parenthesised part to be exact,
>   The reference to the APIC ID being 0xff is because 0xff is broadcast
>   and lowest priority (what the RH bit really is for X86) is illegal
>   with broadcast.
> 
> Can you also check if RH=1 does something to delivery mode?
> 
> Thanks.
> 

Sure, I'll look into that as well.

-James

  reply	other threads:[~2015-03-20 15:24 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
2015-03-20 15:15           ` Radim Krčmář
2015-03-20 15:22             ` James Sullivan [this message]
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=550C3B23.30401@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.