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 ;) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
