On 03/23/2015 03:13 PM, Radim Krčmář wrote: > 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.) > Hmm, any thoughts on how I could test for that? >> 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 ;) > Very true :) -- 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
