[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56154AB4.1050509@scylladb.com>
Date: Wed, 7 Oct 2015 19:39:16 +0300
From: Avi Kivity <avi@...lladb.com>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: "Michael S. Tsirkin" <mst@...hat.com>,
Vlad Zolotarov <vladz@...udius-systems.com>,
Greg KH <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, hjk@...sjkoch.de, corbet@....net,
bruce.richardson@...el.com, avi@...udius-systems.com,
gleb@...udius-systems.com, stephen@...workplumber.org,
alexander.duyck@...il.com
Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support
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
>>> already doing completely unsafe things with uio. vfio should be
>>> enlightened at least to the point that it allows only privileged users
>>> access to devices under such a (lack of) iommu.
>> There is an additional complication. With an iommu, userspace programs
>> the device with virtual addresses, but without it, they have to program
>> physical addresses. So vfio would need to communicate this bit of
>> information.
>>
>> We can go further and define a better translation API than the current
>> one (reading /proc/pagemap). But it's going to be a bigger change to
>> vfio than I thought at first.
> 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 mapping code would need to be aware of the difference. Still, I
> do really prefer to keep vfio as only exposing a secure, iommu protected
> device to the user because surely someone will try and users would
> expect that removing iommu restrictions from vfio means they can do
> device assignment to VMs w/o an iommu.
That's what I thought as well, but apparently adding msix support to the
already insecure uio drivers is even worse.
--
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