search for: progif

...sort that out for powerpc and I can't find a way to make that work that isn't a complete pile of stinking shit. I'm very tempted to go back to my original idea: virtio itself should indicate it's "bypassing ability" via the virtio config space or some other bit (like the ProgIf of the PCI header etc...). I don't see how I can make it work otherwise. The problem with the statement "it's a platform matter" is that: ? - It's not entirely correct. It's actually a feature of a specific virtio implementation (qemu's) that it bypasses all the pla...

...sort that out for powerpc and I can't find a way to make that work that isn't a complete pile of stinking shit. I'm very tempted to go back to my original idea: virtio itself should indicate it's "bypassing ability" via the virtio config space or some other bit (like the ProgIf of the PCI header etc...). I don't see how I can make it work otherwise. The problem with the statement "it's a platform matter" is that: ? - It's not entirely correct. It's actually a feature of a specific virtio implementation (qemu's) that it bypasses all the pla...

...icks with the passed through device configuration space... Note that the above can be solved via some kind of compromise: The device self describes the ability to honor the iommu, along with the property (or ACPI table entry) that indicates whether or not it does. IE. We could use the revision or ProgIf field of the config space for example. Or something in virtio config. If it's an "old" device, we know it always bypass. If it's a new device, we know it only bypasses if the corresponding property is in. I still would have to sort out the openbios case for mac among others but it...

...icks with the passed through device configuration space... Note that the above can be solved via some kind of compromise: The device self describes the ability to honor the iommu, along with the property (or ACPI table entry) that indicates whether or not it does. IE. We could use the revision or ProgIf field of the config space for example. Or something in virtio config. If it's an "old" device, we know it always bypass. If it's a new device, we know it only bypasses if the corresponding property is in. I still would have to sort out the openbios case for mac among others but it...

...pc and I can't find a way > to make that work that isn't a complete pile of stinking shit. > > I'm very tempted to go back to my original idea: virtio itself should > indicate it's "bypassing ability" via the virtio config space or some > other bit (like the ProgIf of the PCI header etc...). > > I don't see how I can make it work otherwise. > > The problem with the statement "it's a platform matter" is that: > > - It's not entirely correct. It's actually a feature of a specific > virtio implementation (qemu'...

...> configuration space... > > Note that the above can be solved via some kind of compromise: The > device self describes the ability to honor the iommu, along with the > property (or ACPI table entry) that indicates whether or not it does. > > IE. We could use the revision or ProgIf field of the config space for > example. Or something in virtio config. If it's an "old" device, we > know it always bypass. If it's a new device, we know it only bypasses > if the corresponding property is in. I still would have to sort out > the > openbios case fo...

...rtio devices honor the IOMMU. > > Note that the above can be solved via some kind of compromise: The > device self describes the ability to honor the iommu, along with the > property (or ACPI table entry) that indicates whether or not it does. > > IE. We could use the revision or ProgIf field of the config space for > example. Or something in virtio config. If it's an "old" device, we > know it always bypass. If it's a new device, we know it only bypasses > if the corresponding property is in. I still would have to sort out the > openbios case for mac...

...*/ -static void __devinit quirk_dunord ( struct pci_dev * dev ) +static void quirk_dunord ( struct pci_dev * dev ) { struct resource *r = &dev->resource [1]; r->start = 0; @@ -992,7 +992,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_DUNORD, PCI_DEVICE_ID_DUNORD_I3000, quirk * in the ProgIf. Unfortunately, the ProgIf value is wrong - 0x80 * instead of 0x01. */ -static void __devinit quirk_transparent_bridge(struct pci_dev *dev) +static void quirk_transparent_bridge(struct pci_dev *dev) { dev->transparent = 1; } @@ -1066,7 +1066,7 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR...

...*/ -static void __devinit quirk_dunord ( struct pci_dev * dev ) +static void quirk_dunord ( struct pci_dev * dev ) { struct resource *r = &dev->resource [1]; r->start = 0; @@ -992,7 +992,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_DUNORD, PCI_DEVICE_ID_DUNORD_I3000, quirk * in the ProgIf. Unfortunately, the ProgIf value is wrong - 0x80 * instead of 0x01. */ -static void __devinit quirk_transparent_bridge(struct pci_dev *dev) +static void quirk_transparent_bridge(struct pci_dev *dev) { dev->transparent = 1; } @@ -1066,7 +1066,7 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR...

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. This appears to work on native and Xen x86_64 using both modern and legacy virtio-pci. It also appears to work on arm and arm64. It definitely won't work as-is on s390x, and

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. This appears to work on native and Xen x86_64 using both modern and legacy virtio-pci. It also appears to work on arm and arm64. It definitely won't work as-is on s390x, and