[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2004281542010.29217@sstabellini-ThinkPad-T480s>
Date: Tue, 28 Apr 2020 15:53:55 -0700 (PDT)
From: Stefano Stabellini <sstabellini@...nel.org>
To: Srivatsa Vaddagiri <vatsa@...eaurora.org>
cc: konrad.wilk@...cle.com, mst@...hat.com, jasowang@...hat.com,
jan.kiszka@...mens.com, will@...nel.org,
stefano.stabellini@...inx.com, iommu@...ts.linux-foundation.org,
virtualization@...ts.linux-foundation.org,
virtio-dev@...ts.oasis-open.org, tsoni@...eaurora.org,
pratikp@...eaurora.org, christoffer.dall@....com,
alex.bennee@...aro.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] virtio: Add bounce DMA ops
On Tue, 28 Apr 2020, Srivatsa Vaddagiri wrote:
> For better security, its desirable that a guest VM's memory is
> not accessible to any entity that executes outside the context of
> guest VM. In case of virtio, backend drivers execute outside the
> context of guest VM and in general will need access to complete
> guest VM memory. One option to restrict the access provided to
> backend driver is to make use of a bounce buffer. The bounce
> buffer is accessible to both backend and frontend drivers. All IO
> buffers that are in private space of guest VM are bounced to be
> accessible to backend.
[...]
> +static int __init virtio_bounce_setup(struct reserved_mem *rmem)
> +{
> + unsigned long node = rmem->fdt_node;
> +
> + if (!of_get_flat_dt_prop(node, "no-map", NULL))
> + return -EINVAL;
> +
> + return virtio_register_bounce_buffer(rmem->base, rmem->size);
> +}
> +
> +RESERVEDMEM_OF_DECLARE(virtio, "virtio_bounce_pool", virtio_bounce_setup);
Is this special reserved-memory region documented somewhere?
Powered by blists - more mailing lists