similar to: [PATCH] virtio: Update spec address

On Tue, Dec 03, 2013 at 12:40:21PM +0000, Mark Brown wrote: > From: Mark Brown <broonie at linaro.org> > > According to the README at the existing URL the spec has moved to github > so update the documentation to match. > > Signed-off-by: Mark Brown <broonie at linaro.org> Even that's no longer accurate :) There should be a new address RSN, I'll respond.

On Thu, Jun 21, 2018 at 08:06:51PM +0100, Jean-Philippe Brucker wrote: > A virtio-mmio node may represent a virtio-iommu device. This is discovered > by the virtio driver at probe time, but the DMA topology isn't > discoverable and must be described by firmware. For DT the standard IOMMU > description is used, as specified in bindings/iommu/iommu.txt and >

On Thu, Jun 21, 2018 at 08:06:51PM +0100, Jean-Philippe Brucker wrote: > A virtio-mmio node may represent a virtio-iommu device. This is discovered > by the virtio driver at probe time, but the DMA topology isn't > discoverable and must be described by firmware. For DT the standard IOMMU > description is used, as specified in bindings/iommu/iommu.txt and >

On Tue, Jun 26, 2018 at 11:59 AM Jean-Philippe Brucker <jean-philippe.brucker at arm.com> wrote: > > On 25/06/18 20:27, Rob Herring wrote: > > On Thu, Jun 21, 2018 at 08:06:51PM +0100, Jean-Philippe Brucker wrote: > >> A virtio-mmio node may represent a virtio-iommu device. This is discovered > >> by the virtio driver at probe time, but the DMA topology

By forcing on DMA API usage for ARM systems, we have inadvertently kicked open a hornets' nest in terms of cache-coherency. Namely that unless the virtio device is explicitly described as capable of coherent DMA by firmware, the DMA APIs on ARM and other DT-based platforms will assume it is non-coherent. This turns out to cause a big problem for the likes of QEMU and kvmtool, which generate

By forcing on DMA API usage for ARM systems, we have inadvertently kicked open a hornets' nest in terms of cache-coherency. Namely that unless the virtio device is explicitly described as capable of coherent DMA by firmware, the DMA APIs on ARM and other DT-based platforms will assume it is non-coherent. This turns out to cause a big problem for the likes of QEMU and kvmtool, which generate

On Tue, Nov 01, 2011 at 10:39:08AM +1030, Rusty Russell wrote: > * [new tag] rusty at rustcorp.com.au-v3.1-7196-gac5be1e -> rusty at rustcorp.com.au-v3.1-7196-gac5be1e > > The following changes since commit 839d8810747bbf39e0a5a7f223b67bffa7945f8d: > > Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging (2011-10-30

On Tue, Nov 01, 2011 at 10:39:08AM +1030, Rusty Russell wrote: > * [new tag] rusty at rustcorp.com.au-v3.1-7196-gac5be1e -> rusty at rustcorp.com.au-v3.1-7196-gac5be1e > > The following changes since commit 839d8810747bbf39e0a5a7f223b67bffa7945f8d: > > Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging (2011-10-30

Whilst always using the DMA API is OK on ARM systems in most cases, there can be a problem if a hypervisor fails to tell its guest that a virtio device is cache-coherent. In that case, the guest will end up making non-cacheable mappings for DMA buffers (i.e. the vring), which, if the host is using a cacheable view of the same buffer on the other end, is not a recipe for success. It turns out that

Whilst always using the DMA API is OK on ARM systems in most cases, there can be a problem if a hypervisor fails to tell its guest that a virtio device is cache-coherent. In that case, the guest will end up making non-cacheable mappings for DMA buffers (i.e. the vring), which, if the host is using a cacheable view of the same buffer on the other end, is not a recipe for success. It turns out that

On Thursday, May 30, 2019 1:23:53 AM CEST Mauro Carvalho Chehab wrote: > Mostly due to x86 and acpi conversion, several documentation > links are still pointing to the old file. Fix them. For the Italian documentation I just send I patch to fix them in a dedicated patch > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung at kernel.org> > --- >

On Thursday, May 30, 2019 1:23:53 AM CEST Mauro Carvalho Chehab wrote: > Mostly due to x86 and acpi conversion, several documentation > links are still pointing to the old file. Fix them. For the Italian documentation I just send I patch to fix them in a dedicated patch > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung at kernel.org> > --- >

Mostly due to x86 and acpi conversion, several documentation links are still pointing to the old file. Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung at kernel.org> --- Documentation/acpi/dsd/leds.txt | 2 +- Documentation/admin-guide/kernel-parameters.rst | 6 +++--- Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++--------

Hi Michael, On 11/27/18 5:53 PM, Michael S. Tsirkin wrote: > On Thu, Nov 22, 2018 at 07:37:54PM +0000, Jean-Philippe Brucker wrote: >> Implement the virtio-iommu driver, following specification v0.9 [1]. >> >> Since v4 [2] I fixed the issues reported by Eric, and added Reviewed-by >> from Eric and Rob. Thanks! >> >> I changed the specification to fix one

Hi Michael, On 11/27/18 5:53 PM, Michael S. Tsirkin wrote: > On Thu, Nov 22, 2018 at 07:37:54PM +0000, Jean-Philippe Brucker wrote: >> Implement the virtio-iommu driver, following specification v0.9 [1]. >> >> Since v4 [2] I fixed the issues reported by Eric, and added Reviewed-by >> from Eric and Rob. Thanks! >> >> I changed the specification to fix one

Fix several warnings and broken links. This series was generated against linux-next, but was rebased to be applied at docs-next. It should apply cleanly on either tree. There's a git tree with all of them applied on the top of docs/docs-next at: https://git.linuxtv.org/mchehab/experimental.git/log/?h=fix_doc_links_v2 Mauro Carvalho Chehab (21): ABI: sysfs-devices-system-cpu: point to

On Thu, Sep 4, 2014 at 7:31 PM, Rusty Russell <rusty at rustcorp.com.au> wrote: > Andy Lutomirski <luto at amacapital.net> writes: >> On Sep 2, 2014 11:53 PM, "Rusty Russell" <rusty at rustcorp.com.au> wrote: >>> >>> Andy Lutomirski <luto at amacapital.net> writes: >>> > There really are virtio devices that are pieces of

On Thu, Sep 4, 2014 at 7:31 PM, Rusty Russell <rusty at rustcorp.com.au> wrote: > Andy Lutomirski <luto at amacapital.net> writes: >> On Sep 2, 2014 11:53 PM, "Rusty Russell" <rusty at rustcorp.com.au> wrote: >>> >>> Andy Lutomirski <luto at amacapital.net> writes: >>> > There really are virtio devices that are pieces of

Implement the virtio-iommu driver, following specification v0.9 [1]. Only minor changes since v5 [2]. I fixed issues reported by Michael and added tags from Eric and Bharat. Thanks! You can find Linux driver and kvmtool device on v0.9 branches [3], module and x86 support on virtio-iommu/devel. Also tested with Eric's QEMU device [4]. [1] Virtio-iommu specification v0.9, sources and pdf

Implement the virtio-iommu driver, following specification v0.9 [1]. Only minor changes since v5 [2]. I fixed issues reported by Michael and added tags from Eric and Bharat. Thanks! You can find Linux driver and kvmtool device on v0.9 branches [3], module and x86 support on virtio-iommu/devel. Also tested with Eric's QEMU device [4]. [1] Virtio-iommu specification v0.9, sources and pdf