Re: [Patch v5] x86: irq_comm: Add check for RH bit in kvm_set_msi_irq

["Radim Krčmář" <rkrcmar@redhat.com>]

2015-03-20 11:50-0600, James Sullivan:
> On 03/20/2015 09:22 AM, James Sullivan wrote:
> > 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').

Thanks, it's possible that the behavior of chipsets changed since the
report on Intel's forum ...
(Lowest priority behaved differently before QPI, so it might coincide.)

> >> 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?
> 
> I haven't seen any changes in the MSI Data Register for any values of RH,
> but I don't have a great sample size (one machine with one set of PCI devices),
> so if anyone else can confirm that I would appreciate it.

I meant if the delivery mode from data register isn't ignored with RH=1,
and the message delivered as if lowest-priority was set there.
(Decided by having something else than fixed or lowest-priority there.)

> Worth noting that low prio delivery was used across the board for my PCI devices
> regardless of RH=1 or 0, so it doesn't seem to be de facto the case that the RH
> bit's only purpose is for lowprio delivery on x86.

Yeah, afaik, it can be done with lowest priority delivery mode on ia64
too, so I have a hard time finding RH's intended purpose.

>                                                    Again, need to have some more
> PCI devices to test against to confirm anything.

It's impossible to test everything, and there is no conflict if we have
at most one data point ;)