On 29.06.21 09:37, Sven Peter wrote:
On Mon, Jun 28, 2021, at 12:54, Alexander Graf wrote:
On 27.06.21 16:34, Sven Peter wrote:
Apple's DART iommu uses a pagetable format that shares some
similarities with the ones already implemented by io-pgtable.c.
Add a new format variant to su
On 27.06.21 16:34, Sven Peter wrote:
Apple's DART iommu uses a pagetable format that shares some
similarities with the ones already implemented by io-pgtable.c.
Add a new format variant to support the required differences
so that we don't have to duplicate the pagetable handling code.
Signed
On 24.02.20 18:16, Christoph Hellwig wrote:
On Sat, Feb 22, 2020 at 02:07:58PM -0500, Michael S. Tsirkin wrote:
On Fri, Feb 21, 2020 at 03:33:40PM +0100, Halil Pasic wrote:
AFAIU you have a positive attitude towards the idea, that
!F_VIRTIO_PLATFORM implies 'no DMA API is used by virtio'
should
On 30.03.20 15:40, Konrad Rzeszutek Wilk wrote:
On Mon, Mar 30, 2020 at 02:06:01PM +0800, Kairui Song wrote:
On Sat, Mar 28, 2020 at 7:57 PM Dave Young wrote:
On 03/26/20 at 05:29pm, Alexander Graf wrote:
The swiotlb is a very convenient fallback mechanism for bounce buffering of
On 26.03.20 18:05, Christoph Hellwig wrote:
On Thu, Mar 26, 2020 at 05:29:22PM +0100, Alexander Graf wrote:
The swiotlb is a very convenient fallback mechanism for bounce buffering of
DMAable data. It is usually used for the compatibility case where devices
can only DMA to a "low r
I'm sure other people will find the functionality useful going forward
though and extend it to be triggered by DT/ACPI in the future.
Signed-off-by: Alexander Graf
---
Documentation/admin-guide/kernel-parameters.txt | 3 +-
Documentation/x86/x86_64/boot-options.
> Am 01.09.2015 um 17:29 schrieb Eric Auger :
>
> Dear all,
>
> I am currently investigating the usage of sysfs to retrieve info from
> the host device tree to build guest dt node for assigned devices (just
> to explain a bit of context for Peter & Alex added in cc). For more
> complex devices
Hi,
While trying to get a sense for performance of i40e and i40evf, I
figured I'd try and create a VF device on the host and activate it.
However, as soon as I brought the VF up, my host became unreachable. The
kernel is current 4.1-rc4.
Main network is connected through ixgbe (eth1), i40e is on
Signed-off-by: Kim Phillips
Looks largely identical to the PCI version of the same that has been
accepted for v3.16 and ack'd by GregKH.
Reviewed-by: Alex Williamson
Yup, would be great to have feature parity for device binding on
platform and PCI.
Reviewed-by
prevent driver
matches.
Signed-off-by: Alex Williamson
Cc: Greg Kroah-Hartman
Reviewed-by: Alexander Graf
I suppose Konrad's RB stays as well?
Alex
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
const char *buf, size_t count)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ char *driver_override, *old = pdev->driver_override, *cp;
+
+ if (count > PATH_MAX)
+ return -EINVAL;
+
+ driver_override = kstrndup(buf, cou
> Am 26.03.2014 um 22:40 schrieb Konrad Rzeszutek Wilk :
>
>> On Wed, Mar 26, 2014 at 01:40:32AM +, Stuart Yoder wrote:
>> Hi Greg,
>>
>> We (Linaro, Freescale, Virtual Open Systems) are trying get an issue
>> closed that has been perculating for a while around creating a mechanism
>> that
On 01.10.2013, at 21:21, Yoder Stuart-B08248 wrote:
>>> static int __init vfio_iommu_type1_init(void)
>>> {
>>> - if (!iommu_present(&pci_bus_type))
>>> +#ifdef CONFIG_PCI
>>> + if (iommu_present(&pci_bus_type)) {
>>> + iommu_bus_type = &pci_bus_type;
>>> + /* For PCI targ
On 02.10.2013, at 13:21, Antonios Motakis wrote:
> On Tue, Oct 1, 2013 at 9:32 PM, Yoder Stuart-B08248
> wrote:
>>> Antonios Motakis wrote
Alex Williamson wrote:
I notice all the open firmware calls here and I'm curious,
will all platform devices be making use of open firmware?
>
14 matches
Mail list logo
