> cmd_p->hdr.ctx_id =
>
> Before this completion of this hypercall, this resource can be
> considered context local, while afterward it can be considered
> "exported".
Maybe I'm misunderstanding render contexts, but exporting a resource
doesn't seem related to render contexts. The other resource
On 02.03.20 18:40, Alexander Duyck wrote:
> Reviewed-by: Alexander Duyck
Thanks a lot Alex!
--
Thanks,
David / dhildenb
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail:
On 02.03.20 19:29, Michal Hocko wrote:
> On Mon 02-03-20 19:15:09, David Hildenbrand wrote:
> [...]
>> As requested by Michal, I will squash some patches.
>
> Just to clarify. If I am the only one to care then do not bother.
Oh, I do bother about your review comments a lot :) And pulling out the
On 02.03.20 14:49, David Hildenbrand wrote:
> This series is based on latest linux-next. The patches are located at:
> https://github.com/davidhildenbrand/linux.git virtio-mem-v1
>
> The basic idea of virtio-mem is to provide a flexible,
> cross-architecture memory hot(un)plug solution that
On Mon, 2020-03-02 at 14:49 +0100, David Hildenbrand wrote:
> 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
On Mon, Mar 2, 2020 at 4:15 AM David Stevens wrote:
>
> 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
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
---
v5->v6 changes:
1. Add the direction of the jack to the configuration of the
On 02.03.20 15:05, Michal Hocko wrote:
> On Mon 02-03-20 14:49:34, David Hildenbrand wrote:
>> A virtio-mem device wants to allocate memory from the memory region it
>> manages in order to unplug it in the hypervisor - similar to
>> a balloon driver. Also, it might want to plug previously
On 02.03.20 15:03, Michal Hocko wrote:
> On Mon 02-03-20 14:49:31, David Hildenbrand wrote:
>> Will be needed by virtio-mem to identify the node from a pxm.
>
> No objection to export the symbol. But it is almost always better to add
> the export in the patch that actually uses it. The intention
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
Let's start with a retry interval of 30 seconds and double the time until
we reach 30 minutes, in case we keep getting errors. Reset the retry
interval in case we succeeded.
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: Oscar Salvador
Cc: Michal Hocko
Cc: Igor Mammedov
Cc: Dave Young
Cc:
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 1636ce4613e3..fc7371c4b7eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
Dropping the reference count of PageOffline() pages allows offlining
code to skip them. However, we also have to convert PG_reserved to
another flag - let's use PG_dirty - so has_unmovable_pages() will
properly handle them. PG_reserved pages get detected as unmovable right
away.
We need the flag
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
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
A virtio-mem device wants to allocate memory from the memory region it
manages in order to unplug it in the hypervisor - similar to
a balloon driver. Also, it might want to plug previously unplugged
(allocated) memory and give it back to Linux. alloc_contig_range() /
free_contig_range() seem to be
We can use alloc_contig_range() to try to unplug subblocks. Unplugged
blocks will be marked PG_offline, however, don't have the PG_reserved
flag set. This way, we can differentiate these allocated subblocks from
subblocks that were never onlined and handle them properly in
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
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.
Will be needed by virtio-mem to identify the node from a pxm.
Acked-by: "Rafael J. Wysocki"
Cc: Len Brown
Cc: linux-a...@vger.kernel.org
Signed-off-by: David Hildenbrand
---
drivers/acpi/numa/srat.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/numa/srat.c
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v1
The basic idea of virtio-mem is to provide a flexible,
cross-architecture memory hot(un)plug solution that avoids many limitations
imposed by existing
On Mon, Mar 2, 2020 at 2:17 PM Rob Miller wrote:
>
> I think it would be good to have a means to negotiate which types of RSS that
> a device is willing to do. Perhaps a CTRLQ command to get RSS capabilities
> then only set those. For example, if a device wishes not to RSS on UDPx but
> will
On 02.03.20 13:48, Michal Hocko wrote:
> On Tue 25-02-20 15:27:28, David Hildenbrand wrote:
>> On 25.02.20 15:11, Michal Hocko wrote:
>>> On Thu 12-12-19 18:11:32, David Hildenbrand wrote:
virtio-mem wants to offline and remove a memory block once it unplugged
all subblocks (e.g., using
On 02.03.20 13:13, Michael S. Tsirkin wrote:
On Mon, Mar 02, 2020 at 07:01:37AM -0500, Rob Miller wrote:
In reviewing my comments, I agree that I misunderstood what was being
requested. Please ignore my comments and continue as needed.
OK then. Jan should we start the vote?
Fine with me,
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 | 19
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 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
---
This change exposes dma-buf's get_uuid callback to PRIME drivers.
Signed-off-by: David Stevens
---
drivers/gpu/drm/drm_prime.c | 27 +++
include/drm/drm_drv.h | 15 +++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c
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
On Mon, Mar 02, 2020 at 07:01:37AM -0500, Rob Miller wrote:
> In reviewing my comments, I agree that I misunderstood what was being
> requested. Please ignore my comments and continue as needed.
OK then. Jan should we start the vote?
Can we add some words about the new fields in the virtio_net_hdr
structure, such as SHOULD, MUST,...
Also, should the virtio_net_hdr be bumped to v2?
Rob Miller
rob.mil...@broadcom.com
(919)721-3339
On Sun, Mar 1, 2020 at 9:33 AM Yuri Benditovich
wrote:
> VIRTIO_NET_F_RSC_EXT feature bit
In reviewing my comments, I agree that I misunderstood what was being
requested. Please ignore my comments and continue as needed.
Rob Miller
rob.mil...@broadcom.com
(919)721-3339
On Thu, Feb 27, 2020 at 5:05 AM Michael S. Tsirkin wrote:
> On Mon, Nov 11, 2019 at 06:26:58PM +0100, Jan Kiszka
The feature VIRTIO_NET_F_HASH_REPORT extends the
layout of the packet and requests the device to
calculate hash on incoming packets and report it
in the packet header.
Signed-off-by: Yuri Benditovich
---
include/uapi/linux/virtio_net.h | 36 +
1 file changed, 36
This series introduce virtio-net features VIRTIO_NET_F_RSC_EXT,
VIRTIO_NET_F_RSS and VIRTIO_NET_F_HASH_REPORT.
Changes from v3: reformatted structure in patch 1
Yuri Benditovich (3):
virtio-net: Introduce extended RSC feature
virtio-net: Introduce RSS receive steering feature
virtio-net:
VIRTIO_NET_F_RSC_EXT feature bit indicates that the device
is able to provide extended RSC information. When the feature
is negotiatede and 'gso_type' field in received packet is not
GSO_NONE, the device reports number of coalesced packets in
'csum_start' field and number of duplicated acks in
RSS (Receive-side scaling) defines hash calculation
rules and decision on receive virtqueue according to
the calculated hash, provided mask to apply and
provided indirection table containing indices of
receive virqueues. The driver sends the control
command to enable multiqueue and provide
On Mon, Mar 02, 2020 at 12:58:34PM +0200, Yuri Benditovich wrote:
> All the classes of commands are defined without indentation.
> All the commands are defined with indentation of 1 space.
> Only the last one (VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET at the end of
> the file) does not have an
All the classes of commands are defined without indentation.
All the commands are defined with indentation of 1 space.
Only the last one (VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET at the end of
the file) does not have an indentation.
On Mon, Mar 2, 2020 at 12:54 PM Michael S. Tsirkin wrote:
>
> On Mon,
On Mon, Mar 02, 2020 at 10:53:14AM +0200, Yuri Benditovich wrote:
> On Sun, Mar 1, 2020 at 9:58 PM Michael S. Tsirkin wrote:
> >
> > On Sun, Mar 01, 2020 at 04:33:01PM +0200, Yuri Benditovich wrote:
> > > RSS (Receive-side scaling) defines hash calculation
> > > rules and decision on receive
On 28.02.2020 12:14, Gerd Hoffmann wrote:
On Thu, Feb 27, 2020 at 03:08:59PM +0100, Anton Yakovlev wrote:
Hello all,
We have completed the implementation of the PoC specification v5. Below are
our comments on what might or should be improved in the specification.
Initialization:
1. I think
On Mon, 2 Mar 2020 11:24:50 +0900
David Stevens wrote:
> On Fri, Feb 28, 2020 at 7:30 PM Gerd Hoffmann wrote:
> >
> > On Fri, Feb 28, 2020 at 07:11:40PM +0900, David Stevens wrote:
> > > > But there also is "unix socket", or maybe a somewhat broader "stream",
> > > > which would be another
On Sun, Mar 1, 2020 at 9:58 PM Michael S. Tsirkin wrote:
>
> On Sun, Mar 01, 2020 at 04:33:01PM +0200, Yuri Benditovich wrote:
> > RSS (Receive-side scaling) defines hash calculation
> > rules and decision on receive virtqueue according to
> > the calculated hash, provided mask to apply and
> >
42 matches
Mail list logo
