[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1170102731.26655.277.camel@localhost.localdomain>
Date: Tue, 30 Jan 2007 07:32:10 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: michael@...erman.id.au
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
David Miller <davem@...emloft.net>, jeff@...zik.org,
greg@...ah.com, tony.luck@...el.com, grundler@...isc-linux.org,
mingo@...e.hu, linux-kernel@...r.kernel.org, kyle@...isc-linux.org,
linuxppc-dev@...abs.org, brice@...i.com, shaohua.li@...el.com,
linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [PATCH 0/6] MSI portability cleanups
> You can read config space, but it's not clear to me if the HV is allowed
> to filter it and hide things.
I've seen it do it for example with EADS bridges. I haven't seen doing
it with devices (other than hiding entire functions) but I wouldn't
exclude it...
> It's also possible that the device
> supports MSI, but for some reason the HV doesn't allow it on that device
> etc. so you really have to ask the HV if it's enabled. So pci_find_cap()
> shouldn't crash or anything, but it may lie to you.
Yup.
> One thing I did like about my code, is that pci_enable_msi() and
> pci_enable_msix() are just small wrappers around generic_enable_msi() -
> which does all the work, and is the same regardless of whether it's an
> MSI or MSI-X. Although that's facilitated by the type arg which you
> don't like.
Part of the reason is you make MSI look like MSI-X (a vector of 1 entry)
while Eric does the opposite.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists