On Thu, Oct 08, 2015 at 08:39:10PM +0300, Michael S. Tsirkin wrote:
> > Why? Greg is against ioctl interface so it will be reworked, by besides
> > that what is wrong with the concept of binding msi-x interrupt to
> > eventfd?
>
> It's not the binding. Managing msi-x just needs more than the puny
On Thu, Oct 08, 2015 at 08:39:10PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 08:01:21PM +0300, Gleb Natapov wrote:
> > On Thu, Oct 08, 2015 at 07:43:04PM +0300, Michael S. Tsirkin wrote:
> > > On Thu, Oct 08, 2015 at 04:28:34PM +0300, Gleb Natapov wrote:
> > > > On Thu, Oct 08, 201
On Thu, Oct 08, 2015 at 08:01:21PM +0300, Gleb Natapov wrote:
> On Thu, Oct 08, 2015 at 07:43:04PM +0300, Michael S. Tsirkin wrote:
> > On Thu, Oct 08, 2015 at 04:28:34PM +0300, Gleb Natapov wrote:
> > > On Thu, Oct 08, 2015 at 04:20:04PM +0300, Michael S. Tsirkin wrote:
> > > > On Thu, Oct 08, 201
On Thu, Oct 08, 2015 at 07:43:04PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 04:28:34PM +0300, Gleb Natapov wrote:
> > On Thu, Oct 08, 2015 at 04:20:04PM +0300, Michael S. Tsirkin wrote:
> > > On Thu, Oct 08, 2015 at 03:27:37PM +0300, Gleb Natapov wrote:
> > > > On Thu, Oct 08, 201
On Thu, Oct 08, 2015 at 04:28:34PM +0300, Gleb Natapov wrote:
> On Thu, Oct 08, 2015 at 04:20:04PM +0300, Michael S. Tsirkin wrote:
> > On Thu, Oct 08, 2015 at 03:27:37PM +0300, Gleb Natapov wrote:
> > > On Thu, Oct 08, 2015 at 03:06:07PM +0300, Michael S. Tsirkin wrote:
> > > > On Thu, Oct 08, 201
On Thu, 2015-10-08 at 16:20 +0300, Avi Kivity wrote:
> On 10/08/2015 01:26 PM, Michael S. Tsirkin wrote:
> > On Thu, Oct 08, 2015 at 12:19:20PM +0300, Avi Kivity wrote:
> >> We are in the strange situation that the Alex is open to adding an insecure
> >> mode to vfio,
> > I don't find this strange.
On Thu, Oct 08, 2015 at 04:20:12PM +0300, Avi Kivity wrote:
> On 10/08/2015 01:26 PM, Michael S. Tsirkin wrote:
> >On Thu, Oct 08, 2015 at 12:19:20PM +0300, Avi Kivity wrote:
> >>
> >>On 10/08/2015 11:32 AM, Michael S. Tsirkin wrote:
> >>>On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
On Thu, Oct 08, 2015 at 04:20:04PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 03:27:37PM +0300, Gleb Natapov wrote:
> > On Thu, Oct 08, 2015 at 03:06:07PM +0300, Michael S. Tsirkin wrote:
> > > On Thu, Oct 08, 2015 at 12:44:09PM +0300, Avi Kivity wrote:
> > > >
> > > >
> > > > On
On 10/08/2015 01:26 PM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 12:19:20PM +0300, Avi Kivity wrote:
On 10/08/2015 11:32 AM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
On 08/10/15 00:05, Michael S. Tsirkin wrote:
On Wed, Oct 07, 2015 at 07:
On Thu, Oct 08, 2015 at 03:27:37PM +0300, Gleb Natapov wrote:
> On Thu, Oct 08, 2015 at 03:06:07PM +0300, Michael S. Tsirkin wrote:
> > On Thu, Oct 08, 2015 at 12:44:09PM +0300, Avi Kivity wrote:
> > >
> > >
> > > On 10/08/2015 12:16 PM, Michael S. Tsirkin wrote:
> > > >On Thu, Oct 08, 2015 at 11
On Thu, Oct 08, 2015 at 03:06:07PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 12:44:09PM +0300, Avi Kivity wrote:
> >
> >
> > On 10/08/2015 12:16 PM, Michael S. Tsirkin wrote:
> > >On Thu, Oct 08, 2015 at 11:46:30AM +0300, Avi Kivity wrote:
> > >>
> > >>On 10/08/2015 10:32 AM, Mic
On Thu, Oct 08, 2015 at 12:45:08PM +0300, Gleb Natapov wrote:
> On Thu, Oct 08, 2015 at 12:38:28PM +0300, Michael S. Tsirkin wrote:
> > On Thu, Oct 08, 2015 at 10:59:10AM +0300, Gleb Natapov wrote:
> > > I do not remember this been an issue when uio_generic was accepted
> > > into the kernel. The r
On Thu, Oct 08, 2015 at 12:44:09PM +0300, Avi Kivity wrote:
>
>
> On 10/08/2015 12:16 PM, Michael S. Tsirkin wrote:
> >On Thu, Oct 08, 2015 at 11:46:30AM +0300, Avi Kivity wrote:
> >>
> >>On 10/08/2015 10:32 AM, Michael S. Tsirkin wrote:
> >>>On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity w
On Thu, Oct 08, 2015 at 12:19:20PM +0300, Avi Kivity wrote:
>
>
> On 10/08/2015 11:32 AM, Michael S. Tsirkin wrote:
> >On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
> >>On 08/10/15 00:05, Michael S. Tsirkin wrote:
> >>>On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
> >>
On Thu, Oct 08, 2015 at 12:38:28PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 10:59:10AM +0300, Gleb Natapov wrote:
> > I do not remember this been an issue when uio_generic was accepted
> > into the kernel. The reason was because it meant to be accessible by root
> > only.
>
> No
On 10/08/2015 12:16 PM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 11:46:30AM +0300, Avi Kivity wrote:
On 10/08/2015 10:32 AM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
It is good practice to defend against root oopsing the kernel, but in s
On Thu, Oct 08, 2015 at 10:59:10AM +0300, Gleb Natapov wrote:
> I do not remember this been an issue when uio_generic was accepted
> into the kernel. The reason was because it meant to be accessible by root
> only.
No - because it does not need bus mastering. So it can be used safely
with some dev
On 10/08/2015 11:32 AM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
On 08/10/15 00:05, Michael S. Tsirkin wrote:
On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
That's what I thought as well, but apparently adding msix support to the
alre
On Thu, Oct 08, 2015 at 11:46:30AM +0300, Avi Kivity wrote:
>
>
> On 10/08/2015 10:32 AM, Michael S. Tsirkin wrote:
> >On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
> >>It is good practice to defend against root oopsing the kernel, but in some
> >>cases it cannot be achieved.
> >Abs
On Thu, Oct 08, 2015 at 11:32:50AM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
> > On 08/10/15 00:05, Michael S. Tsirkin wrote:
> > >On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
> > >>That's what I thought as well, but apparently add
On Wed, Oct 07, 2015 at 10:55:30AM +0300, Vlad Zolotarov wrote:
> * not safe - UIO
That's wrong. UIO (in particular uio_pci_generic) can be used
safely in many ways, for example with any device not doing DMA. I
wouldn't put it upstream otherwise.
Make your driver work in such a way that it can
On 10/08/2015 10:32 AM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
It is good practice to defend against root oopsing the kernel, but in some
cases it cannot be achieved.
Absolutely. That's one of the issues with these patches. They don't even
try wh
On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
> On 08/10/15 00:05, Michael S. Tsirkin wrote:
> >On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
> >>That's what I thought as well, but apparently adding msix support to the
> >>already insecure uio drivers is even worse.
> >I
On Thu, Oct 08, 2015 at 10:41:53AM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 07:19:13AM +0300, Gleb Natapov wrote:
> > Well
> > the alternative is to add /dev/vfio/nommu like you've said, but what
> > would be the difference between this and uio eludes me.
>
> Are you familiar wit
On Thu, Oct 08, 2015 at 07:19:13AM +0300, Gleb Natapov wrote:
> Well
> the alternative is to add /dev/vfio/nommu like you've said, but what
> would be the difference between this and uio eludes me.
Are you familiar with vfio that you ask such a question?
Here's the vfio pci code:
$ wc -l drivers
On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
> It is good practice to defend against root oopsing the kernel, but in some
> cases it cannot be achieved.
Absolutely. That's one of the issues with these patches. They don't even
try where it's absolutely possible.
--
MST
--
To unsubs
On 08/10/15 00:05, Michael S. Tsirkin wrote:
On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
That's what I thought as well, but apparently adding msix support to the
already insecure uio drivers is even worse.
I'm glad you finally agree what these drivers are doing is insecure.
A
On Thu, Oct 08, 2015 at 12:05:11AM +0300, Michael S. Tsirkin wrote:
> On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
> > That's what I thought as well, but apparently adding msix support to the
> > already insecure uio drivers is even worse.
>
> I'm glad you finally agree what these d
On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
> That's what I thought as well, but apparently adding msix support to the
> already insecure uio drivers is even worse.
I'm glad you finally agree what these drivers are doing is insecure.
And basically kernel cares about security, no o
On Wed, Oct 07, 2015 at 10:31:04AM -0600, Alex Williamson wrote:
> It sounds like a separate vfio iommu backend from type1, one that just
> pins the page and returns the bus address. The curse and benefit would
> be that existing type1 users wouldn't "just work" in an insecure mode,
> the DMA mapp
On 10/07/2015 07:31 PM, Alex Williamson wrote:
I
guess the no-iommu map would error if the IOVA isn't simply the bus
address of the page mapped.
Of course this is entirely unsafe and this no-iommu driver should taint
the kernel, but it at least standardizes on one userspace API and you're
On Wed, 2015-10-07 at 09:52 +0300, Avi Kivity wrote:
>
> On 10/06/2015 09:51 PM, Alex Williamson wrote:
> > On Tue, 2015-10-06 at 18:23 +0300, Avi Kivity wrote:
> >> On 10/06/2015 05:56 PM, Michael S. Tsirkin wrote:
> >>> On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote:
> The o
On 10/07/15 11:00, Vlad Zolotarov wrote:
On 10/07/15 09:53, Avi Kivity wrote:
On 10/07/2015 12:58 AM, Stephen Hemminger wrote:
Go ahead and submit a seperate taint bit for UIO as a patch.
Taint should only be applied if bus mastering is enabled (to avoid
annoying the users of the origin
On 10/07/15 09:53, Avi Kivity wrote:
On 10/07/2015 12:58 AM, Stephen Hemminger wrote:
Go ahead and submit a seperate taint bit for UIO as a patch.
Taint should only be applied if bus mastering is enabled (to avoid
annoying the users of the original uio use case)
Pls., note that this seri
On 10/07/15 00:58, Stephen Hemminger wrote:
Go ahead and submit a seperate taint bit for UIO as a patch.
This patch already does this.
thanks,
vlad
On Tue, Oct 6, 2015 at 10:41 PM, Alex Williamson
mailto:alex.william...@redhat.com>> wrote:
On Tue, 2015-10-06 at 22:32 +0100, Stephe
On 10/06/15 21:51, Alex Williamson wrote:
On Tue, 2015-10-06 at 18:23 +0300, Avi Kivity wrote:
On 10/06/2015 05:56 PM, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote:
The only "like VFIO" behavior we implement here is binding the MSI-X
interrupt noti
On 10/06/2015 09:51 PM, Alex Williamson wrote:
On Tue, 2015-10-06 at 18:23 +0300, Avi Kivity wrote:
On 10/06/2015 05:56 PM, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote:
The only "like VFIO" behavior we implement here is binding the MSI-X
interrupt
On Tue, 2015-10-06 at 22:32 +0100, Stephen Hemminger wrote:
> On Tue, 06 Oct 2015 12:51:20 -0600
> Alex Williamson wrote:
>
> > Of course this is entirely unsafe and this no-iommu driver should taint
> > the kernel, but it at least standardizes on one userspace API and you're
> > already doing co
On Tue, 06 Oct 2015 12:51:20 -0600
Alex Williamson wrote:
> Of course this is entirely unsafe and this no-iommu driver should taint
> the kernel, but it at least standardizes on one userspace API and you're
> already doing completely unsafe things with uio. vfio should be
> enlightened at least
On Tue, 2015-10-06 at 18:23 +0300, Avi Kivity wrote:
>
> On 10/06/2015 05:56 PM, Michael S. Tsirkin wrote:
> > On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote:
> >> The only "like VFIO" behavior we implement here is binding the MSI-X
> >> interrupt notification to eventfd descriptor
On 10/06/15 17:56, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote:
The only "like VFIO" behavior we implement here is binding the MSI-X
interrupt notification to eventfd descriptor.
There will be more if you add some basic memory protections.
I've a
On 10/06/2015 05:46 PM, Michael S. Tsirkin wrote:
On Mon, Oct 05, 2015 at 11:28:03AM +0300, Avi Kivity wrote:
Eventfd is a natural enough representation of an interrupt; both kvm and
vfio use it, and are also able to share the eventfd, allowing a vfio
interrupt to generate a kvm interrupt, wit
On 10/06/2015 05:56 PM, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote:
The only "like VFIO" behavior we implement here is binding the MSI-X
interrupt notification to eventfd descriptor.
There will be more if you add some basic memory protections.
Be
On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote:
> The only "like VFIO" behavior we implement here is binding the MSI-X
> interrupt notification to eventfd descriptor.
There will be more if you add some basic memory protections.
Besides, that's not true.
Your patch queries MSI capa
On Mon, Oct 05, 2015 at 11:28:03AM +0300, Avi Kivity wrote:
> Eventfd is a natural enough representation of an interrupt; both kvm and
> vfio use it, and are also able to share the eventfd, allowing a vfio
> interrupt to generate a kvm interrupt, without userspace intervention, and
> one day withou
On 10/06/15 17:38, Michael S. Tsirkin wrote:
On Mon, Oct 05, 2015 at 01:20:11PM +0300, Avi Kivity wrote:
On 10/05/2015 12:49 PM, Greg KH wrote:
On Mon, Oct 05, 2015 at 11:28:03AM +0300, Avi Kivity wrote:
Of course it has to be documented, but this just follows vfio.
Eventfd is a natural eno
On Mon, Oct 05, 2015 at 01:20:11PM +0300, Avi Kivity wrote:
> On 10/05/2015 12:49 PM, Greg KH wrote:
> >On Mon, Oct 05, 2015 at 11:28:03AM +0300, Avi Kivity wrote:
> >>Of course it has to be documented, but this just follows vfio.
> >>
> >>Eventfd is a natural enough representation of an interrupt;
On Mon, Oct 05, 2015 at 01:06:09PM +0300, Vlad Zolotarov wrote:
> Having said all that however I'd agree if someone would say that mappings
> setting would rather come as a separate patch in this series... ;)
> it will in v4...
Just drop this is my advice. There are enough controversial things her
On Sun, Oct 04, 2015 at 11:43:17PM +0300, Vlad Zolotarov wrote:
> Add support for MSI and MSI-X interrupt modes:
>- Interrupt mode selection order is:
> INT#X (for backward compatibility) -> MSI-X -> MSI.
>- Add ioctl() commands:
> - UIO_PCI_GENERIC_INT_MODE_GET: query the cur
On Mon, Oct 05, 2015 at 02:09:32PM +0300, Avi Kivity wrote:
> On 10/05/2015 01:57 PM, Greg KH wrote:
> >On Mon, Oct 05, 2015 at 01:48:39PM +0300, Vlad Zolotarov wrote:
> >>
> >>On 10/05/15 10:56, Greg KH wrote:
> >>>On Mon, Oct 05, 2015 at 10:41:39AM +0300, Vlad Zolotarov wrote:
> >>+struct msi
On 10/05/15 14:47, Avi Kivity wrote:
On 10/05/2015 02:41 PM, Vlad Zolotarov wrote:
On 10/05/15 13:57, Greg KH wrote:
On Mon, Oct 05, 2015 at 01:48:39PM +0300, Vlad Zolotarov wrote:
On 10/05/15 10:56, Greg KH wrote:
On Mon, Oct 05, 2015 at 10:41:39AM +0300, Vlad Zolotarov wrote:
+struct
On 10/05/2015 02:41 PM, Vlad Zolotarov wrote:
On 10/05/15 13:57, Greg KH wrote:
On Mon, Oct 05, 2015 at 01:48:39PM +0300, Vlad Zolotarov wrote:
On 10/05/15 10:56, Greg KH wrote:
On Mon, Oct 05, 2015 at 10:41:39AM +0300, Vlad Zolotarov wrote:
+struct msix_info {
+int num_irqs;
+stru
On 10/05/15 13:57, Greg KH wrote:
On Mon, Oct 05, 2015 at 01:48:39PM +0300, Vlad Zolotarov wrote:
On 10/05/15 10:56, Greg KH wrote:
On Mon, Oct 05, 2015 at 10:41:39AM +0300, Vlad Zolotarov wrote:
+struct msix_info {
+ int num_irqs;
+ struct msix_entry *table;
+ struct uio_
On 10/05/2015 01:57 PM, Greg KH wrote:
On Mon, Oct 05, 2015 at 01:48:39PM +0300, Vlad Zolotarov wrote:
On 10/05/15 10:56, Greg KH wrote:
On Mon, Oct 05, 2015 at 10:41:39AM +0300, Vlad Zolotarov wrote:
+struct msix_info {
+ int num_irqs;
+ struct msix_entry *table;
+ struct u
On Mon, Oct 05, 2015 at 01:48:39PM +0300, Vlad Zolotarov wrote:
>
>
> On 10/05/15 10:56, Greg KH wrote:
> >On Mon, Oct 05, 2015 at 10:41:39AM +0300, Vlad Zolotarov wrote:
> +struct msix_info {
> + int num_irqs;
> + struct msix_entry *table;
> + struct uio_msix_irq_ctx {
> +
On 10/05/15 10:56, Greg KH wrote:
On Mon, Oct 05, 2015 at 10:41:39AM +0300, Vlad Zolotarov wrote:
+struct msix_info {
+ int num_irqs;
+ struct msix_entry *table;
+ struct uio_msix_irq_ctx {
+ struct eventfd_ctx *trigger;/* MSI-x vector to eventfd */
Why are
On 10/05/2015 12:49 PM, Greg KH wrote:
On Mon, Oct 05, 2015 at 11:28:03AM +0300, Avi Kivity wrote:
Of course it has to be documented, but this just follows vfio.
Eventfd is a natural enough representation of an interrupt; both kvm and
vfio use it, and are also able to share the eventfd, allowin
On 10/05/15 12:08, Vlad Zolotarov wrote:
On 10/05/15 11:41, Stephen Hemminger wrote:
On Sun, 4 Oct 2015 23:43:17 +0300
Vlad Zolotarov wrote:
+static int setup_maps(struct pci_dev *pdev, struct uio_info *info)
+{
+int i, m = 0, p = 0, err;
+static const char * const bar_names[] =
On Mon, Oct 05, 2015 at 11:28:03AM +0300, Avi Kivity wrote:
> Of course it has to be documented, but this just follows vfio.
>
> Eventfd is a natural enough representation of an interrupt; both kvm and
> vfio use it, and are also able to share the eventfd, allowing a vfio
> interrupt to generate a
On Mon, Oct 05, 2015 at 10:41:39AM +0300, Vlad Zolotarov wrote:
> >>+struct msix_info {
> >>+ int num_irqs;
> >>+ struct msix_entry *table;
> >>+ struct uio_msix_irq_ctx {
> >>+ struct eventfd_ctx *trigger;/* MSI-x vector to eventfd */
> >Why are you using eventfd for msi vector
On 10/05/15 11:41, Stephen Hemminger wrote:
On Sun, 4 Oct 2015 23:43:17 +0300
Vlad Zolotarov wrote:
+static int setup_maps(struct pci_dev *pdev, struct uio_info *info)
+{
+ int i, m = 0, p = 0, err;
+ static const char * const bar_names[] = {
+ "BAR0", "BAR1"
On 10/05/15 11:41, Stephen Hemminger wrote:
On Sun, 4 Oct 2015 23:43:17 +0300
Vlad Zolotarov wrote:
+static int setup_maps(struct pci_dev *pdev, struct uio_info *info)
+{
+ int i, m = 0, p = 0, err;
+ static const char * const bar_names[] = {
+ "BAR0", "BAR1"
On Sun, 4 Oct 2015 23:43:17 +0300
Vlad Zolotarov wrote:
> +static int setup_maps(struct pci_dev *pdev, struct uio_info *info)
> +{
> + int i, m = 0, p = 0, err;
> + static const char * const bar_names[] = {
> + "BAR0", "BAR1", "BAR2", "BAR3", "BAR4", "BAR5",
> + };
> +
>
On 10/05/2015 06:11 AM, Greg KH wrote:
On Sun, Oct 04, 2015 at 11:43:17PM +0300, Vlad Zolotarov wrote:
Add support for MSI and MSI-X interrupt modes:
- Interrupt mode selection order is:
INT#X (for backward compatibility) -> MSI-X -> MSI.
- Add ioctl() commands:
- UIO_PCI
On 10/05/15 06:11, Greg KH wrote:
On Sun, Oct 04, 2015 at 11:43:17PM +0300, Vlad Zolotarov wrote:
Add support for MSI and MSI-X interrupt modes:
- Interrupt mode selection order is:
INT#X (for backward compatibility) -> MSI-X -> MSI.
- Add ioctl() commands:
- UIO_PCI_GE
On Sun, Oct 04, 2015 at 11:43:17PM +0300, Vlad Zolotarov wrote:
> Add support for MSI and MSI-X interrupt modes:
>- Interrupt mode selection order is:
> INT#X (for backward compatibility) -> MSI-X -> MSI.
>- Add ioctl() commands:
> - UIO_PCI_GENERIC_INT_MODE_GET: query the cur
Add support for MSI and MSI-X interrupt modes:
- Interrupt mode selection order is:
INT#X (for backward compatibility) -> MSI-X -> MSI.
- Add ioctl() commands:
- UIO_PCI_GENERIC_INT_MODE_GET: query the current interrupt mode.
- UIO_PCI_GENERIC_IRQ_NUM_GET: query the maximu
Add support for MSI and MSI-X interrupt modes:
- Interrupt mode selection order is:
INT#X (for backward compatibility) -> MSI-X -> MSI.
- Add ioctl() commands:
- UIO_PCI_GENERIC_INT_MODE_GET: query the current interrupt mode.
- UIO_PCI_GENERIC_IRQ_NUM_GET: query the maximu
68 matches
Mail list logo
