On Wed, 11 Mar 2020 17:24:11 +
Stefan Hajnoczi wrote:
> > I thought so - but does any vhost-user implementation assume it has
> > access to the entire of the guests memory space? I can see why that
> > might be seen as undesirable from a security point of view.
>
On s390 we do assume we
On Mon, Mar 09, 2020 at 05:42:39PM +, Alex Bennée wrote:
>
> Srivatsa Vaddagiri writes:
>
> > On Mon, Mar 9, 2020 at 9:16 PM Stefan Hajnoczi wrote:
> >>
> >> That already exists today. Pick a vhost-user device implementation from
> >> QEMU, DPDK/SPDK, or rust-vmm and run it with your VMM
On Mon, Mar 09, 2020 at 04:43:31PM +, Alex Bennée wrote:
>
> Stefan Hajnoczi writes:
>
> > On Fri, Mar 06, 2020 at 06:33:57PM +, Alex Bennée wrote:
> >> So the context of my question is what sort of common software layer is
> >> required to implement a virtio backend entirely in
On 11.03.20 18:14, David Hildenbrand wrote:
> virtio-mem wants to offline and remove a memory block once it unplugged
> all subblocks (e.g., using alloc_contig_range()). Let's provide
> an interface to do that from a driver. virtio-mem already supports to
> offline partially unplugged memory
Let's make sure patches/bug reports find the right person.
Cc: "Michael S. Tsirkin"
Signed-off-by: David Hildenbrand
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f6dcd1233935..ee0e7cbca5c6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
Let's start with a retry interval of 5 seconds and double the time until
we reach 5 minutes, in case we keep getting errors. Reset the retry
interval in case we succeeded.
The two main reasons for having to retry are
- The hypervisor is busy and cannot process our request
- We cannot reach the
Let's offline+remove memory blocks once all subblocks are unplugged. We
can use the new Linux MM interface for that. As no memory is in use
anymore, this shouldn't take a long time and shouldn't fail. There might
be corner cases where the offlining could still fail (especially, if
another notifier
Dropping the reference count of PageOffline() pages during MEM_GOING_ONLINE
allows offlining code to skip them. However, we also have to clear
PG_reserved, because PG_reserved pages get detected as unmovable right
away. Take care of restoring the reference count when offlining is
canceled.
virtio-mem wants to allow to offline memory blocks of which some parts
were unplugged (allocated via alloc_contig_range()), especially, to later
offline and remove completely unplugged memory blocks. The important part
is that PageOffline() has to remain set until the section is offline, so
these
virtio-mem wants to offline and remove a memory block once it unplugged
all subblocks (e.g., using alloc_contig_range()). Let's provide
an interface to do that from a driver. virtio-mem already supports to
offline partially unplugged memory blocks. Offlining a fully unplugged
memory block will not
Each virtio-mem device owns exactly one memory region. It is responsible
for adding/removing memory from that memory region on request.
When the device driver starts up, the requested amount of memory is
queried and then plugged to Linux. On request, further memory can be
plugged or unplugged.
Unplugging subblocks of memory blocks that are offline is easy. All we
have to do is watch out for concurrent onlining activity.
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: Oscar Salvador
Cc: Michal Hocko
Cc: Igor Mammedov
Cc: Dave Young
Cc: Andrew Morton
Cc: Dan Williams
Cc: Pavel
We want to allow to specify (similar as for a DIMM), to which node a
virtio-mem device (and, therefore, its memory) belongs. Add a new
virtio-mem feature flag and export pxm_to_node, so it can be used in kernel
module context.
Acked-by: Michal Hocko # for the export
Acked-by: "Rafael J. Wysocki"
We also want to unplug online memory (contained in online memory blocks
and, therefore, managed by the buddy), and eventually replug it later.
When requested to unplug memory, we use alloc_contig_range() to allocate
subblocks in online memory blocks (so we are the owner) and send them to
our
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v2
I now have acks for all !virtio-mem changes. I'll be happy to get review
feedback, testing reports, etc. for the virtio-mem changes. If there are
no further
This patch proposes virtio specification for a new virtio sound device,
that may be useful in case when having audio is required but a device
passthrough or emulation is not an option.
Signed-off-by: Anton Yakovlev
---
v6 -> v7 changes:
1. Add more detailed rationale of relationships with the
This change exposes dma-buf's get_uuid callback to PRIME drivers.
Signed-off-by: David Stevens
---
drivers/gpu/drm/drm_prime.c | 23 +++
include/drm/drm_drv.h | 10 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c
This change adds a new dma-buf operation that allows dma-bufs to be used
by virtio drivers to share exported objects. The new operation allows
the importing driver to query the exporting driver for the UUID which
identifies the underlying exported object.
Signed-off-by: David Stevens
---
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++
drivers/gpu/drm/virtio/virtgpu_drv.h | 18 +
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
This patchset implements the current proposal for virtio cross-device
resource sharing [1], with minor changes based on recent comments. It
is expected that this will be used to import virtio resources into the
virtio-video driver currently under discussion [2].
This patchset adds a new hook to
21 matches
Mail list logo
