Messages in this thread | | | Date | Tue, 30 Jan 2007 10:05:45 +1100 | From | Paul Mackerras <> | Subject | Re: [PATCH 0/6] MSI portability cleanups |
| |
Benjamin Herrenschmidt writes:
> > I'd hate to hit a different Hypervisor that did something close but > > not quite the same and have the code fail then. So definitely > > avoiding touching pci config space at all in the calls seems to make a > > lot of sense. This includes avoiding pci_find_capability right? > > Quite possibly yes. I'm pretty sure it will work on IBM HV but we aren't > really supposed to use it...
Actually, I don't know of any reason why we can't use pci_find_capability. We are supposed to avoid trying to touch config space of devices (in fact, functions) that aren't assigned to our partition, but we're not talking about that here.
I just got an answer from the hypervisor architects. It turns out that the hardware _does_ prevent the device from sending MSI messages to another partition. The OS _can_ write whatever it likes to the MSI address and data registers. It can potentially lose interrupts (or, I expect, get the device isolated by EEH) but it can't disrupt another partition.
I think the reason why the hypervisor call writes the values straight into the MSI/MSI-X registers in the device is (a) that's convenient for AIX, since it saves it from immediately having to do more calls into the hypervisor to write those values to the device, and (b) there are some ABI complications in returning a lot of values, so the device registers provide a convenient place to return those values.
So it would be possible, although gross, to do the hypervisor call, read the values from config space and return them to the generic code, then let the generic code write them to config space for us. :P
The remaining point of difference then seems to be that for MSI-X, we really want to know up-front how many interrupts the device driver is asking for, rather than having a series of alloc requests dribble in one at a time.
Regards, Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |