* Re: [PATCH net] virtio-net: keep vnet header zeroed after processing XDP
From: David Miller @ 2018-12-01 1:25 UTC (permalink / raw)
To: jasowang; +Cc: netdev, virtualization, linux-kernel, mst
In-Reply-To: <20181129055316.24090-1-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Thu, 29 Nov 2018 13:53:16 +0800
> We copy vnet header unconditionally in page_to_skb() this is wrong
> since XDP may modify the packet data. So let's keep a zeroed vnet
> header for not confusing the conversion between vnet header and skb
> metadata.
>
> In the future, we should able to detect whether or not the packet was
> modified and keep using the vnet header when packet was not touched.
>
> Fixes: f600b6905015 ("virtio_net: Add XDP support")
> Reported-by: Pavel Popa <pashinho1990@gmail.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 01/13] virtio: add packed ring types and macros
From: Tiwei Bie @ 2018-12-01 2:03 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtio-dev, netdev, linux-kernel, virtualization, Maxime Coquelin,
wexu
In-Reply-To: <20181130114501-mutt-send-email-mst@kernel.org>
On Fri, Nov 30, 2018 at 11:46:57AM -0500, Michael S. Tsirkin wrote:
> On Sat, Dec 01, 2018 at 12:24:16AM +0800, Tiwei Bie wrote:
> > On Fri, Nov 30, 2018 at 10:53:07AM -0500, Michael S. Tsirkin wrote:
> > > On Fri, Nov 30, 2018 at 11:37:37PM +0800, Tiwei Bie wrote:
> > > > On Fri, Nov 30, 2018 at 08:52:42AM -0500, Michael S. Tsirkin wrote:
> > > > > On Fri, Nov 30, 2018 at 02:01:06PM +0100, Maxime Coquelin wrote:
> > > > > > On 11/30/18 1:47 PM, Michael S. Tsirkin wrote:
> > > > > > > On Fri, Nov 30, 2018 at 05:53:40PM +0800, Tiwei Bie wrote:
> > > > > > > > On Fri, Nov 30, 2018 at 04:10:55PM +0800, Jason Wang wrote:
> > > > > > > > >
> > > > > > > > > On 2018/11/21 下午6:03, Tiwei Bie wrote:
> > > > > > > > > > Add types and macros for packed ring.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> > > > > > > > > > ---
> > > > > > > > > > include/uapi/linux/virtio_config.h | 3 +++
> > > > > > > > > > include/uapi/linux/virtio_ring.h | 52 ++++++++++++++++++++++++++++++++++++++
> > > > > > > > > > 2 files changed, 55 insertions(+)
> > > > > > > > > >
> > > > > > > > > > diff --git a/include/uapi/linux/virtio_config.h b/include/uapi/linux/virtio_config.h
> > > > > > > > > > index 449132c76b1c..1196e1c1d4f6 100644
> > > > > > > > > > --- a/include/uapi/linux/virtio_config.h
> > > > > > > > > > +++ b/include/uapi/linux/virtio_config.h
> > > > > > > > > > @@ -75,6 +75,9 @@
> > > > > > > > > > */
> > > > > > > > > > #define VIRTIO_F_IOMMU_PLATFORM 33
> > > > > > > > > > +/* This feature indicates support for the packed virtqueue layout. */
> > > > > > > > > > +#define VIRTIO_F_RING_PACKED 34
> > > > > > > > > > +
> > > > > > > > > > /*
> > > > > > > > > > * Does the device support Single Root I/O Virtualization?
> > > > > > > > > > */
> > > > > > > > > > diff --git a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h
> > > > > > > > > > index 6d5d5faa989b..2414f8af26b3 100644
> > > > > > > > > > --- a/include/uapi/linux/virtio_ring.h
> > > > > > > > > > +++ b/include/uapi/linux/virtio_ring.h
> > > > > > > > > > @@ -44,6 +44,13 @@
> > > > > > > > > > /* This means the buffer contains a list of buffer descriptors. */
> > > > > > > > > > #define VRING_DESC_F_INDIRECT 4
> > > > > > > > > > +/*
> > > > > > > > > > + * Mark a descriptor as available or used in packed ring.
> > > > > > > > > > + * Notice: they are defined as shifts instead of shifted values.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > This looks inconsistent to previous flags, any reason for using shifts?
> > > > > > > >
> > > > > > > > Yeah, it was suggested to use shifts, as _F_ should be a bit
> > > > > > > > number, not a shifted value:
> > > > > > > >
> > > > > > > > https://patchwork.ozlabs.org/patch/942296/#1989390
> > > > > > >
> > > > > > > But let's add a _SPLIT_ variant that uses shifts consistently.
> > > > > >
> > > > > > Maybe we could avoid adding SPLIT and PACKED, but define as follow:
> > > > > >
> > > > > > #define VRING_DESC_F_INDIRECT_SHIFT 2
> > > > > > #define VRING_DESC_F_INDIRECT (1ull << VRING_DESC_F_INDIRECT_SHIFT)
> > > > > >
> > > > > > #define VRING_DESC_F_AVAIL_SHIFT 7
> > > > > > #define VRING_DESC_F_AVAIL (1ull << VRING_DESC_F_AVAIL_SHIFT)
> > > > > >
> > > > > > I think it would be better for consistency.
> > > > >
> > > > > I don't think that will help. the problem is that
> > > > > most of the existing virtio code consistently uses _F_ as shifts.
> > > > > So we just need to do something about these 5 being inconsistent:
> > > > >
> > > > > include/uapi/linux/virtio_ring.h:#define VRING_DESC_F_NEXT 1
> > > > > include/uapi/linux/virtio_ring.h:#define VRING_DESC_F_WRITE 2
> > > > > include/uapi/linux/virtio_ring.h:#define VRING_DESC_F_INDIRECT 4
> > > > > include/uapi/linux/virtio_ring.h:#define VRING_USED_F_NO_NOTIFY 1
> > > > > include/uapi/linux/virtio_ring.h:#define VRING_AVAIL_F_NO_INTERRUPT 1
> > > > >
> > > > > I do not want all of virtio to become verbose with _SHIFT, ergo
> > > > > we need to change the above 5 to have names which are with _F_ and
> > > > > have the bit number.
> > > >
> > > > How about something like this:
> > > >
> > > > #define VRING_COMM_DESC_F_NEXT 0
> > > > #define VRING_COMM_DESC_F_WRITE 1
> > > > #define VRING_COMM_DESC_F_INDIRECT 2
> > > >
> > > > #define VRING_SPLIT_USED_F_NO_NOTIFY 0
> > > > #define VRING_SPLIT_AVAIL_F_NO_INTERRUPT 0
> > > >
> > > > or
> > > >
> > > > #define VRING_SPLIT_DESC_F_NEXT 0
> > > > #define VRING_SPLIT_DESC_F_WRITE 1
> > > > #define VRING_SPLIT_DESC_F_INDIRECT 2
> > > >
> > > > #define VRING_SPLIT_USED_F_NO_NOTIFY 0
> > > > #define VRING_SPLIT_AVAIL_F_NO_INTERRUPT 0
> > > >
> > > > #define VRING_PACKED_DESC_F_NEXT 0
> > > > #define VRING_PACKED_DESC_F_WRITE 1
> > > > #define VRING_PACKED_DESC_F_INDIRECT 2
> > >
> > > As we aren't sharing code I think I prefer the second form.
> > > Maybe add VRING_NO_LEGACY so people can audit their code
> > > for assumptions?
> >
> > Maybe it's better to name it as VIRTIO_RING_NO_LEGACY
> > which is more consistent with the names in other files.
>
> OK
>
> > >
> > > We also want to guard layout definitions at the end of that file
> > > I think.
> >
> > Do you mean guard the definitions of `struct vring` and
> > `struct vring_packed` with _NO_LEGACY?
>
> I really mean vring_size/vring_init/vring_used_event/vring_avail_event
> these are pre- virtio 1 and should be disabled when
> building with no legacy.
>
> But yes I would say let's make sure people can set a flag and
> find all dependencies of the split layout in their code easily.
I see. Thanks!
>
> > >
> > > > >
> > > > >
> > > > >
> > > > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > + */
> > > > > > > > > > +#define VRING_PACKED_DESC_F_AVAIL 7
> > > > > > > > > > +#define VRING_PACKED_DESC_F_USED 15
> > > > > > > > > > +
> > > > > > > > > > /* The Host uses this in used->flags to advise the Guest: don't kick me when
> > > > > > > > > > * you add a buffer. It's unreliable, so it's simply an optimization. Guest
> > > > > > > > > > * will still kick if it's out of buffers. */
> > > > > > > > > > @@ -53,6 +60,23 @@
> > > > > > > > > > * optimization. */
> > > > > > > > > > #define VRING_AVAIL_F_NO_INTERRUPT 1
> > > > > > > > > > +/* Enable events in packed ring. */
> > > > > > > > > > +#define VRING_PACKED_EVENT_FLAG_ENABLE 0x0
> > > > > > > > > > +/* Disable events in packed ring. */
> > > > > > > > > > +#define VRING_PACKED_EVENT_FLAG_DISABLE 0x1
> > > > > > > > > > +/*
> > > > > > > > > > + * Enable events for a specific descriptor in packed ring.
> > > > > > > > > > + * (as specified by Descriptor Ring Change Event Offset/Wrap Counter).
> > > > > > > > > > + * Only valid if VIRTIO_RING_F_EVENT_IDX has been negotiated.
> > > > > > > > > > + */
> > > > > > > > > > +#define VRING_PACKED_EVENT_FLAG_DESC 0x2
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Any reason for using _FLAG_ instead of _F_?
> > > > > > > >
> > > > > > > > Yeah, it was suggested to not use _F_, as these are values,
> > > > > > > > should not have _F_:
> > > > > > > >
> > > > > > > > https://patchwork.ozlabs.org/patch/942296/#1989390
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Tiwei
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > +
> > > > > > > > > > +/*
> > > > > > > > > > + * Wrap counter bit shift in event suppression structure
> > > > > > > > > > + * of packed ring.
> > > > > > > > > > + */
> > > > > > > > > > +#define VRING_PACKED_EVENT_F_WRAP_CTR 15
> > > > > > > > > > +
> > > > > > > > > > /* We support indirect buffer descriptors */
> > > > > > > > > > #define VIRTIO_RING_F_INDIRECT_DESC 28
> > > > > > > > > > @@ -171,4 +195,32 @@ static inline int vring_need_event(__u16 event_idx, __u16 new_idx, __u16 old)
> > > > > > > > > > return (__u16)(new_idx - event_idx - 1) < (__u16)(new_idx - old);
> > > > > > > > > > }
> > > > > > > > > > +struct vring_packed_desc_event {
> > > > > > > > > > + /* Descriptor Ring Change Event Offset/Wrap Counter. */
> > > > > > > > > > + __le16 off_wrap;
> > > > > > > > > > + /* Descriptor Ring Change Event Flags. */
> > > > > > > > > > + __le16 flags;
> > > > > > > > > > +};
> > > > > > > > > > +
> > > > > > > > > > +struct vring_packed_desc {
> > > > > > > > > > + /* Buffer Address. */
> > > > > > > > > > + __le64 addr;
> > > > > > > > > > + /* Buffer Length. */
> > > > > > > > > > + __le32 len;
> > > > > > > > > > + /* Buffer ID. */
> > > > > > > > > > + __le16 id;
> > > > > > > > > > + /* The flags depending on descriptor type. */
> > > > > > > > > > + __le16 flags;
> > > > > > > > > > +};
> > > > > > > > > > +
> > > > > > > > > > +struct vring_packed {
> > > > > > > > > > + unsigned int num;
> > > > > > > > > > +
> > > > > > > > > > + struct vring_packed_desc *desc;
> > > > > > > > > > +
> > > > > > > > > > + struct vring_packed_desc_event *driver;
> > > > > > > > > > +
> > > > > > > > > > + struct vring_packed_desc_event *device;
> > > > > > > > > > +};
> > > > > > > > > > +
> > > > > > > > > > #endif /* _UAPI_LINUX_VIRTIO_RING_H */
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-12-03 3:10 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang; +Cc: virtualization, kvm, stefanha, netdev
In-Reply-To: <20181130083540-mutt-send-email-mst@kernel.org>
On 2018/11/30 21:40, Michael S. Tsirkin wrote:
> On Fri, Nov 30, 2018 at 09:10:03PM +0800, Jason Wang wrote:
>>
>> On 2018/11/30 下午8:55, Jason Wang wrote:
>>>
>>> On 2018/11/30 下午8:52, Michael S. Tsirkin wrote:
>>>>>> If you want to compare it with
>>>>>> something that would be TCP or QUIC. The fundamental
>>>>>> difference between
>>>>>> virtio-vsock and e.g. TCP is that TCP operates in a packet
>>>>>> loss environment.
>>>>>> So they are using timers for reliability, and receiver is
>>>>>> always free to
>>>>>> discard any unacked data.
>>>>> Virtio-net knows nothing above L2, so they are totally
>>>>> transparent to device
>>>>> itself. I still don't get why not using virtio-net instead.
>>>>>
>>>>>
>>>>> Thanks
>>>> Is your question why is virtio-vsock used instead of TCP on top of IP
>>>> on top of virtio-net?
>>>>
>>>>
>>>
>>> No, my question is why not do vsock through virtio-net.
>>>
>>> Thanks
>>>
>>
>> Just to clarify, it's not about vosck over ethernet, and it's not about
>> inventing new features or APIs. It's probably something like:
>>
>> - Let virtio-net driver probe vsock device and do vosck specific things if
>> needed to share as much codes.
>>
>> - A new kind of sockfd (which is vsock based) for vhost-net for it to do
>> vsock specific things (hopefully it can be transparent).
>>
>> The change should be totally transparent to userspace applications.
>>
>> Thanks
>
> Which code is duplicated between virtio vsock and virtio net right now?
>
Hi Michael,
AFAIK, there is almost no duplicate code between virtio vsock and virtio net now.
But, if virtio vsock wants to support mergeable rx buffer and multiqueue feature,
it has some duplicate codes from virtio net. Based on it, we both think vsock
may use virtio net as a transport channel, in this way, vsock can use some of
virtio net great features.
Thanks,
Yiwen.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 0/5] VSOCK: support mergeable rx buffer in vhost-vsock
From: jiangyiwen @ 2018-12-03 6:08 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: netdev, kvm, virtualization
In-Reply-To: <20181129141928.GC17554@stefanha-x1.localdomain>
On 2018/11/29 22:19, Stefan Hajnoczi wrote:
> On Tue, Nov 06, 2018 at 01:53:54PM +0800, jiangyiwen wrote:
>> On 2018/11/6 11:32, Jason Wang wrote:
>>>
>>> On 2018/11/6 上午11:17, jiangyiwen wrote:
>>>> On 2018/11/6 10:41, Jason Wang wrote:
>>>>> On 2018/11/6 上午10:17, jiangyiwen wrote:
>>>>>> On 2018/11/5 17:21, Jason Wang wrote:
>>>>>>> On 2018/11/5 下午3:43, jiangyiwen wrote:
>>>>>>>> Now vsock only support send/receive small packet, it can't achieve
>>>>>>>> high performance. As previous discussed with Jason Wang, I revisit the
>>>>>>>> idea of vhost-net about mergeable rx buffer and implement the mergeable
>>>>>>>> rx buffer in vhost-vsock, it can allow big packet to be scattered in
>>>>>>>> into different buffers and improve performance obviously.
>>>>>>>>
>>>>>>>> I write a tool to test the vhost-vsock performance, mainly send big
>>>>>>>> packet(64K) included guest->Host and Host->Guest. The result as
>>>>>>>> follows:
>>>>>>>>
>>>>>>>> Before performance:
>>>>>>>> Single socket Multiple sockets(Max Bandwidth)
>>>>>>>> Guest->Host ~400MB/s ~480MB/s
>>>>>>>> Host->Guest ~1450MB/s ~1600MB/s
>>>>>>>>
>>>>>>>> After performance:
>>>>>>>> Single socket Multiple sockets(Max Bandwidth)
>>>>>>>> Guest->Host ~1700MB/s ~2900MB/s
>>>>>>>> Host->Guest ~1700MB/s ~2900MB/s
>>>>>>>>
>>>>>>>> From the test results, the performance is improved obviously, and guest
>>>>>>>> memory will not be wasted.
>>>>>>> Hi:
>>>>>>>
>>>>>>> Thanks for the patches and the numbers are really impressive.
>>>>>>>
>>>>>>> But instead of duplicating codes between sock and net. I was considering to use virtio-net as a transport of vsock. Then we may have all existed features likes batching, mergeable rx buffers and multiqueue. Want to consider this idea? Thoughts?
>>>>>>>
>>>>>>>
>>>>>> Hi Jason,
>>>>>>
>>>>>> I am not very familiar with virtio-net, so I am afraid I can't give too
>>>>>> much effective advice. Then I have several problems:
>>>>>>
>>>>>> 1. If use virtio-net as a transport, guest should see a virtio-net
>>>>>> device instead of virtio-vsock device, right? Is vsock only as a
>>>>>> transport between socket and net_device? User should still use
>>>>>> AF_VSOCK type to create socket, right?
>>>>>
>>>>> Well, there're many choices. What you need is just to keep the socket API and hide the implementation. For example, you can keep the vosck device in guest and switch to use vhost-net in host. We probably need a new feature bit or header to let vhost know we are passing vsock packet. And vhost-net could forward the packet to vsock core on host.
>>>>>
>>>>>
>>>>>> 2. I want to know if this idea has already started, and how is
>>>>>> the current progress?
>>>>>
>>>>> Not yet started. Just want to listen from the community. If this sounds good, do you have interest in implementing this?
>>>>>
>>>>>
>>>>>> 3. And what is stefan's idea?
>>>>>
>>>>> Talk with Stefan a little on this during KVM Forum. I think he tends to agree on this idea. Anyway, let's wait for his reply.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>> Hi Jason,
>>>>
>>>> Thanks your reply, what you want is try to avoid duplicate code, and still
>>>> use the existed features with virtio-net.
>>>
>>>
>>> Yes, technically we can use virtio-net driver is guest as well but we could do it step by step.
>>>
>>>
>>>> Yes, if this sounds good and most people can recognize this idea, I am very
>>>> happy to implement this.
>>>
>>>
>>> Cool, thanks.
>>>
>>>
>>>>
>>>> In addition, I hope you can review these patches before the new idea is
>>>> implemented, after all the performance can be improved. :-)
>>>
>>>
>>> Ok.
>>>
>>>
>>> So the patch actually did three things:
>>>
>>> - mergeable buffer implementation
>>>
>>> - increase the default rx buffer size
>>>
>>> - add used and signal guest in a batch
>>>
>>> It would be helpful if you can measure the performance improvement independently. This can give reviewer a better understanding on how much did each part help.
>>>
>>> Thanks
>>>
>>>
>>
>> Great, I will test the performance independently in the later version.
>
> I'm catching up on email so maybe you've already discussed this, but a
> key design point in virtio-vsock is reliable in-order delivery. When
> using virtio-net code it's important to keep those properties so that
> AF_VSOCK SOCK_STREAM sockets work as expected. Packets must not be
> reordered or dropped.
>
> In addition, there's the virtio-vsock flow control scheme that allows
> multiple sockets to share a ring without starvation or denial-of-service
> problems. The guest knows how much socket buffer space is available on
> the host (and vice versa). A well-behaved guest only sends up to the
> available buffer space so that the host can copy the data into the
> socket buffer and free up ring space for other sockets. This scheme is
> how virtio-vsock achieves guaranteed delivery while avoiding starvation
> or denial-of-service.
>
> So you'll need to use some kind of framing (protocol) that preserves
> these properties on top of virtio-net. This framing could be based on
> virtio-vsock's packet headers.
>
> Stefan
>
Hi Stefan,
I find some different ideas from MST. He think that use virtio-net as
vsock's transport channel is not of much value in another discussion.
So we may need to discuss which solution we should use:
1. vsock over virtio-net
2. add multiqueue and mergeable rx buffer feature in existing virtio-vsock.
Stefan, what's your suggestion?
Thanks,
Yiwen.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v5 0/7] Add virtio-iommu driver
From: Auger Eric @ 2018-12-03 13:27 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: mark.rutland, virtio-dev, lorenzo.pieralisi, tnowicki, devicetree,
Jean-Philippe Brucker, linux-pci, joro, will.deacon, robin.murphy,
virtualization, marc.zyngier, iommu, robh+dt, kvmarm, bhelgaas
In-Reply-To: <20181127121036-mutt-send-email-mst@kernel.org>
Hi Michael,
On 11/27/18 6:16 PM, Michael S. Tsirkin wrote:
> On Tue, Nov 27, 2018 at 06:09:25PM +0100, Auger Eric wrote:
>> 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 inconsistency discussed in v4.
>>>> That the device fills the probe buffer with zeroes is now a "SHOULD"
>>>> instead of a "MAY", since it's the only way for the driver to know if
>>>> the device wrote the status. Existing devices already do this. In
>>>> addition the device now needs to fill the three padding bytes at the
>>>> tail with zeroes.
>>>>
>>>> You can find Linux driver and kvmtool device on branches
>>>> virtio-iommu/v0.9 [3]. I also lightly tested with Eric's latest QEMU
>>>> device [4].
>>>
>>> I tried to get this to work on my x86 box but without
>>> success. Any hints? Does this have to do with the IORT table?
>>> I think we really should just reserve our own table ID
>>> and avoid the pain of trying to add things to the IORT spec.
>>> I'm reluctant to merge lots of code that I can't easily test.
>>> Again, if we found a way to push more configuration into
>>> virtio config space the problem space would be smaller.
>>
>> You can at least test it with QEMU ARM virt in TCG mode.
>
> It's slow enough that I generally just focus on KVM.
>
>> Then I have
>> worked on the IORT integration in PC/Q35 but this is not yet functional.
>> I need to debug what's wrong on guest ACPI probing. I plan to work on
>> this this week.
>>
>> Thanks
>>
>> Eric
>
> Sounds good. Did you need to make changes to IORT? I don't remember. If
> yes it would be very easy to just have a virtio specific ACPI table -
> I am assuming ARM guys will be just as hostile to virt changes
> to IORT as they were to minor changes to ARM vIOMMU.
I eventually succeeded to prototype the IORT integration on x86. Please
find below the branches to use for testing:
- QEMU: https://github.com/eauger/qemu.git v3.1.0-rc3-virtio-iommu-v0.9-x86
On top of "[RFC v9 00/17] VIRTIO-IOMMU device", I added the IORT build
for pc machine
- LINUX GUEST: https://github.com/eauger/linux.git
virtio-iommu-v0.9-iort-x86
Jean's virtio-iommu/devel branch + 2 hacks (to be discussed separately)
Make sure the CONFIG_VIRTIO_IOMMU config is set
Used qemu cmd line featuring -device virtio-iommu-pci,addr=0xa:
./x86_64-softmmu/qemu-system-x86_64 -M
q35,accel=kvm,usb=off,sata=off,dump-guest-core=off -cpu
Haswell,-hle,-rtm -smp 4,sockets=4,cores=1,threads=1 -m 4G -display none
--enable-kvm -serial tcp:localhost:4444,server -device
virtio-iommu-pci,addr=0xa -trace
events=/home/augere/UPSTREAM/qemu/hw-virtio-iommu -qmp
unix:/home/augere/TEST/QEMU/qmp-sock,server,nowait -rtc
base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -realtime
mlock=off -no-hpet -no-shutdown -device
virtio-blk-pci,scsi=off,drive=drv0,id=virtio-disk0,bootindex=1,iommu_platform,disable-modern=off,disable-legacy=on
-drive
file=/home/augere/VM/IMAGES/vm0.qcow2,format=qcow2,if=none,id=drv0
-device
virtio-net-pci,bus=pcie.0,netdev=nic0,mac=6a:f5:10:b1:3d:d2,iommu_platform,disable-modern=off,disable-legacy=on
-netdev
tap,id=nic0,script=/home/augere/TEST/SCRIPTS/qemu-ifup,downscript=/home/augere/TEST/SCRIPTS/qemu-ifdown
-kernel
/home/augere/VM/BOOT/vmlinuz-4.20.0-rc3-guest-defconfig-virtio-iommu-0.9-x86+
-initrd
/home/augere/VM/BOOT/initrd.img-4.20.0-rc3-guest-defconfig-virtio-iommu-0.9-x86+
-append 'root=/dev/mapper/rhel_dhcp156--238-root ro crashkernel=auto
rd.lvm.lv=rhel_dhcp156-238/root rd.lvm.lv=rhel_dhcp156-238/swap rw
ignore_loglevel console=tty0 console=ttyS0,115200n8 serial acpi=force'
-net none -d guest_errors
I put sata=off otherwise I have early untranslated transactions that
prevent the guest from booting.
Please let me know if you encounter any issue reproducing the
environment on your side.
Thanks
Eric
>
>
>>>
>>>> [1] Virtio-iommu specification v0.9, sources, pdf and diff from v0.8
>>>> git://linux-arm.org/virtio-iommu.git virtio-iommu/v0.9
>>>> http://jpbrucker.net/virtio-iommu/spec/v0.9/virtio-iommu-v0.9.pdf
>>>> http://jpbrucker.net/virtio-iommu/spec/diffs/virtio-iommu-pdf-diff-v0.8-v0.9.pdf
>>>>
>>>> [2] [PATCH v4 0/7] Add virtio-iommu driver
>>>> https://lists.linuxfoundation.org/pipermail/iommu/2018-November/031074.html
>>>>
>>>> [3] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.9
>>>> git://linux-arm.org/kvmtool-jpb.git virtio-iommu/v0.9
>>>>
>>>> [4] [RFC v9 00/17] VIRTIO-IOMMU device
>>>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg575578.html
>>>>
>>>> Jean-Philippe Brucker (7):
>>>> dt-bindings: virtio-mmio: Add IOMMU description
>>>> dt-bindings: virtio: Add virtio-pci-iommu node
>>>> of: Allow the iommu-map property to omit untranslated devices
>>>> PCI: OF: Initialize dev->fwnode appropriately
>>>> iommu: Add virtio-iommu driver
>>>> iommu/virtio: Add probe request
>>>> iommu/virtio: Add event queue
>>>>
>>>> .../devicetree/bindings/virtio/iommu.txt | 66 +
>>>> .../devicetree/bindings/virtio/mmio.txt | 30 +
>>>> MAINTAINERS | 7 +
>>>> drivers/iommu/Kconfig | 11 +
>>>> drivers/iommu/Makefile | 1 +
>>>> drivers/iommu/virtio-iommu.c | 1157 +++++++++++++++++
>>>> drivers/of/base.c | 10 +-
>>>> drivers/pci/of.c | 7 +
>>>> include/uapi/linux/virtio_ids.h | 1 +
>>>> include/uapi/linux/virtio_iommu.h | 161 +++
>>>> 10 files changed, 1448 insertions(+), 3 deletions(-)
>>>> create mode 100644 Documentation/devicetree/bindings/virtio/iommu.txt
>>>> create mode 100644 drivers/iommu/virtio-iommu.c
>>>> create mode 100644 include/uapi/linux/virtio_iommu.h
>>>>
>>>> --
>>>> 2.19.1
^ permalink raw reply
* Re: [PATCH v2] vhost: fix IOTLB locking
From: David Miller @ 2018-12-03 23:53 UTC (permalink / raw)
To: jean-philippe.brucker; +Cc: kvm, mst, netdev, virtualization
In-Reply-To: <20181130160553.9739-1-jean-philippe.brucker@arm.com>
From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Date: Fri, 30 Nov 2018 16:05:53 +0000
> Commit 78139c94dc8c ("net: vhost: lock the vqs one by one") moved the vq
> lock to improve scalability, but introduced a possible deadlock in
> vhost-iotlb. vhost_iotlb_notify_vq() now takes vq->mutex while holding
> the device's IOTLB spinlock. And on the vhost_iotlb_miss() path, the
> spinlock is taken while holding vq->mutex.
>
> Since calling vhost_poll_queue() doesn't require any lock, avoid the
> deadlock by not taking vq->mutex.
>
> Fixes: 78139c94dc8c ("net: vhost: lock the vqs one by one")
> Acked-by: Jason Wang <jasowang@redhat.com>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Applied, thank you.
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Michael S. Tsirkin @ 2018-12-04 1:31 UTC (permalink / raw)
To: jiangyiwen; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <5C049EC2.3080002@huawei.com>
On Mon, Dec 03, 2018 at 11:10:58AM +0800, jiangyiwen wrote:
> On 2018/11/30 21:40, Michael S. Tsirkin wrote:
> > On Fri, Nov 30, 2018 at 09:10:03PM +0800, Jason Wang wrote:
> >>
> >> On 2018/11/30 下午8:55, Jason Wang wrote:
> >>>
> >>> On 2018/11/30 下午8:52, Michael S. Tsirkin wrote:
> >>>>>> If you want to compare it with
> >>>>>> something that would be TCP or QUIC. The fundamental
> >>>>>> difference between
> >>>>>> virtio-vsock and e.g. TCP is that TCP operates in a packet
> >>>>>> loss environment.
> >>>>>> So they are using timers for reliability, and receiver is
> >>>>>> always free to
> >>>>>> discard any unacked data.
> >>>>> Virtio-net knows nothing above L2, so they are totally
> >>>>> transparent to device
> >>>>> itself. I still don't get why not using virtio-net instead.
> >>>>>
> >>>>>
> >>>>> Thanks
> >>>> Is your question why is virtio-vsock used instead of TCP on top of IP
> >>>> on top of virtio-net?
> >>>>
> >>>>
> >>>
> >>> No, my question is why not do vsock through virtio-net.
> >>>
> >>> Thanks
> >>>
> >>
> >> Just to clarify, it's not about vosck over ethernet, and it's not about
> >> inventing new features or APIs. It's probably something like:
> >>
> >> - Let virtio-net driver probe vsock device and do vosck specific things if
> >> needed to share as much codes.
> >>
> >> - A new kind of sockfd (which is vsock based) for vhost-net for it to do
> >> vsock specific things (hopefully it can be transparent).
> >>
> >> The change should be totally transparent to userspace applications.
> >>
> >> Thanks
> >
> > Which code is duplicated between virtio vsock and virtio net right now?
> >
>
> Hi Michael,
>
> AFAIK, there is almost no duplicate code between virtio vsock and virtio net now.
>
> But, if virtio vsock wants to support mergeable rx buffer and multiqueue feature,
> it has some duplicate codes from virtio net. Based on it, we both think vsock
> may use virtio net as a transport channel, in this way, vsock can use some of
> virtio net great features.
>
> Thanks,
> Yiwen.
What I would do is just copy some code and show a performance
benefit. If that works out it will be clearer which code
should be shared.
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-12-04 2:21 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <20181203202441-mutt-send-email-mst@kernel.org>
On 2018/12/4 9:31, Michael S. Tsirkin wrote:
> On Mon, Dec 03, 2018 at 11:10:58AM +0800, jiangyiwen wrote:
>> On 2018/11/30 21:40, Michael S. Tsirkin wrote:
>>> On Fri, Nov 30, 2018 at 09:10:03PM +0800, Jason Wang wrote:
>>>>
>>>> On 2018/11/30 下午8:55, Jason Wang wrote:
>>>>>
>>>>> On 2018/11/30 下午8:52, Michael S. Tsirkin wrote:
>>>>>>>> If you want to compare it with
>>>>>>>> something that would be TCP or QUIC. The fundamental
>>>>>>>> difference between
>>>>>>>> virtio-vsock and e.g. TCP is that TCP operates in a packet
>>>>>>>> loss environment.
>>>>>>>> So they are using timers for reliability, and receiver is
>>>>>>>> always free to
>>>>>>>> discard any unacked data.
>>>>>>> Virtio-net knows nothing above L2, so they are totally
>>>>>>> transparent to device
>>>>>>> itself. I still don't get why not using virtio-net instead.
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>> Is your question why is virtio-vsock used instead of TCP on top of IP
>>>>>> on top of virtio-net?
>>>>>>
>>>>>>
>>>>>
>>>>> No, my question is why not do vsock through virtio-net.
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>>> Just to clarify, it's not about vosck over ethernet, and it's not about
>>>> inventing new features or APIs. It's probably something like:
>>>>
>>>> - Let virtio-net driver probe vsock device and do vosck specific things if
>>>> needed to share as much codes.
>>>>
>>>> - A new kind of sockfd (which is vsock based) for vhost-net for it to do
>>>> vsock specific things (hopefully it can be transparent).
>>>>
>>>> The change should be totally transparent to userspace applications.
>>>>
>>>> Thanks
>>>
>>> Which code is duplicated between virtio vsock and virtio net right now?
>>>
>>
>> Hi Michael,
>>
>> AFAIK, there is almost no duplicate code between virtio vsock and virtio net now.
>>
>> But, if virtio vsock wants to support mergeable rx buffer and multiqueue feature,
>> it has some duplicate codes from virtio net. Based on it, we both think vsock
>> may use virtio net as a transport channel, in this way, vsock can use some of
>> virtio net great features.
>>
>> Thanks,
>> Yiwen.
>
> What I would do is just copy some code and show a performance
> benefit. If that works out it will be clearer which code
> should be shared.
>
Hi Michael,
I have already sent a series of patches (VSOCK: support mergeable rx buffer in vhost-vsock)
a month ago, and the performance as follows:
I write a tool to test the vhost-vsock performance, mainly send big
packet(64K) included guest->Host and Host->Guest. The result as
follows:
Before performance:
Single socket Multiple sockets(Max Bandwidth)
Guest->Host ~400MB/s ~480MB/s
Host->Guest ~1450MB/s ~1600MB/s
After performance:
Single socket Multiple sockets(Max Bandwidth)
Guest->Host ~1700MB/s ~2900MB/s
Host->Guest ~1700MB/s ~2900MB/s
From the test results, the performance is improved obviously, and guest
memory will not be wasted.
In addition, multiqueue feature I have not implemented it yet.
Thanks,
Yiwen.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Michael S. Tsirkin @ 2018-12-04 4:08 UTC (permalink / raw)
To: jiangyiwen; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <5C05E4B4.3040804@huawei.com>
On Tue, Dec 04, 2018 at 10:21:40AM +0800, jiangyiwen wrote:
> On 2018/12/4 9:31, Michael S. Tsirkin wrote:
> > On Mon, Dec 03, 2018 at 11:10:58AM +0800, jiangyiwen wrote:
> >> On 2018/11/30 21:40, Michael S. Tsirkin wrote:
> >>> On Fri, Nov 30, 2018 at 09:10:03PM +0800, Jason Wang wrote:
> >>>>
> >>>> On 2018/11/30 下午8:55, Jason Wang wrote:
> >>>>>
> >>>>> On 2018/11/30 下午8:52, Michael S. Tsirkin wrote:
> >>>>>>>> If you want to compare it with
> >>>>>>>> something that would be TCP or QUIC. The fundamental
> >>>>>>>> difference between
> >>>>>>>> virtio-vsock and e.g. TCP is that TCP operates in a packet
> >>>>>>>> loss environment.
> >>>>>>>> So they are using timers for reliability, and receiver is
> >>>>>>>> always free to
> >>>>>>>> discard any unacked data.
> >>>>>>> Virtio-net knows nothing above L2, so they are totally
> >>>>>>> transparent to device
> >>>>>>> itself. I still don't get why not using virtio-net instead.
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks
> >>>>>> Is your question why is virtio-vsock used instead of TCP on top of IP
> >>>>>> on top of virtio-net?
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> No, my question is why not do vsock through virtio-net.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>
> >>>> Just to clarify, it's not about vosck over ethernet, and it's not about
> >>>> inventing new features or APIs. It's probably something like:
> >>>>
> >>>> - Let virtio-net driver probe vsock device and do vosck specific things if
> >>>> needed to share as much codes.
> >>>>
> >>>> - A new kind of sockfd (which is vsock based) for vhost-net for it to do
> >>>> vsock specific things (hopefully it can be transparent).
> >>>>
> >>>> The change should be totally transparent to userspace applications.
> >>>>
> >>>> Thanks
> >>>
> >>> Which code is duplicated between virtio vsock and virtio net right now?
> >>>
> >>
> >> Hi Michael,
> >>
> >> AFAIK, there is almost no duplicate code between virtio vsock and virtio net now.
> >>
> >> But, if virtio vsock wants to support mergeable rx buffer and multiqueue feature,
> >> it has some duplicate codes from virtio net. Based on it, we both think vsock
> >> may use virtio net as a transport channel, in this way, vsock can use some of
> >> virtio net great features.
> >>
> >> Thanks,
> >> Yiwen.
> >
> > What I would do is just copy some code and show a performance
> > benefit. If that works out it will be clearer which code
> > should be shared.
> >
>
> Hi Michael,
>
> I have already sent a series of patches (VSOCK: support mergeable rx buffer in vhost-vsock)
> a month ago, and the performance as follows:
>
> I write a tool to test the vhost-vsock performance, mainly send big
> packet(64K) included guest->Host and Host->Guest. The result as
> follows:
>
> Before performance:
> Single socket Multiple sockets(Max Bandwidth)
> Guest->Host ~400MB/s ~480MB/s
> Host->Guest ~1450MB/s ~1600MB/s
>
> After performance:
> Single socket Multiple sockets(Max Bandwidth)
> Guest->Host ~1700MB/s ~2900MB/s
> Host->Guest ~1700MB/s ~2900MB/s
>
> >From the test results, the performance is improved obviously, and guest
> memory will not be wasted.
Oh I didn't see that one. Pls CC me in the future.
Looking at it I agree zero page allocation looks like an issue
but besides that, I think we can merge something similar
and look at refactoring and future extensions later.
However, any interface change (e.g. a new feature) must be CC'd to one of
virtio lists (subscriber-only).
> In addition, multiqueue feature I have not implemented it yet.
>
> Thanks,
> Yiwen.
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-12-04 6:01 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <20181203230459-mutt-send-email-mst@kernel.org>
On 2018/12/4 12:08, Michael S. Tsirkin wrote:
> On Tue, Dec 04, 2018 at 10:21:40AM +0800, jiangyiwen wrote:
>> On 2018/12/4 9:31, Michael S. Tsirkin wrote:
>>> On Mon, Dec 03, 2018 at 11:10:58AM +0800, jiangyiwen wrote:
>>>> On 2018/11/30 21:40, Michael S. Tsirkin wrote:
>>>>> On Fri, Nov 30, 2018 at 09:10:03PM +0800, Jason Wang wrote:
>>>>>>
>>>>>> On 2018/11/30 下午8:55, Jason Wang wrote:
>>>>>>>
>>>>>>> On 2018/11/30 下午8:52, Michael S. Tsirkin wrote:
>>>>>>>>>> If you want to compare it with
>>>>>>>>>> something that would be TCP or QUIC. The fundamental
>>>>>>>>>> difference between
>>>>>>>>>> virtio-vsock and e.g. TCP is that TCP operates in a packet
>>>>>>>>>> loss environment.
>>>>>>>>>> So they are using timers for reliability, and receiver is
>>>>>>>>>> always free to
>>>>>>>>>> discard any unacked data.
>>>>>>>>> Virtio-net knows nothing above L2, so they are totally
>>>>>>>>> transparent to device
>>>>>>>>> itself. I still don't get why not using virtio-net instead.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>> Is your question why is virtio-vsock used instead of TCP on top of IP
>>>>>>>> on top of virtio-net?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> No, my question is why not do vsock through virtio-net.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>
>>>>>> Just to clarify, it's not about vosck over ethernet, and it's not about
>>>>>> inventing new features or APIs. It's probably something like:
>>>>>>
>>>>>> - Let virtio-net driver probe vsock device and do vosck specific things if
>>>>>> needed to share as much codes.
>>>>>>
>>>>>> - A new kind of sockfd (which is vsock based) for vhost-net for it to do
>>>>>> vsock specific things (hopefully it can be transparent).
>>>>>>
>>>>>> The change should be totally transparent to userspace applications.
>>>>>>
>>>>>> Thanks
>>>>>
>>>>> Which code is duplicated between virtio vsock and virtio net right now?
>>>>>
>>>>
>>>> Hi Michael,
>>>>
>>>> AFAIK, there is almost no duplicate code between virtio vsock and virtio net now.
>>>>
>>>> But, if virtio vsock wants to support mergeable rx buffer and multiqueue feature,
>>>> it has some duplicate codes from virtio net. Based on it, we both think vsock
>>>> may use virtio net as a transport channel, in this way, vsock can use some of
>>>> virtio net great features.
>>>>
>>>> Thanks,
>>>> Yiwen.
>>>
>>> What I would do is just copy some code and show a performance
>>> benefit. If that works out it will be clearer which code
>>> should be shared.
>>>
>>
>> Hi Michael,
>>
>> I have already sent a series of patches (VSOCK: support mergeable rx buffer in vhost-vsock)
>> a month ago, and the performance as follows:
>>
>> I write a tool to test the vhost-vsock performance, mainly send big
>> packet(64K) included guest->Host and Host->Guest. The result as
>> follows:
>>
>> Before performance:
>> Single socket Multiple sockets(Max Bandwidth)
>> Guest->Host ~400MB/s ~480MB/s
>> Host->Guest ~1450MB/s ~1600MB/s
>>
>> After performance:
>> Single socket Multiple sockets(Max Bandwidth)
>> Guest->Host ~1700MB/s ~2900MB/s
>> Host->Guest ~1700MB/s ~2900MB/s
>>
>> >From the test results, the performance is improved obviously, and guest
>> memory will not be wasted.
>
> Oh I didn't see that one. Pls CC me in the future.
>
> Looking at it I agree zero page allocation looks like an issue
> but besides that, I think we can merge something similar
> and look at refactoring and future extensions later.
>
> However, any interface change (e.g. a new feature) must be CC'd to one of
> virtio lists (subscriber-only).
>
>
Okay, previously I send Virtio-vsock patch only CC stefan and mailing lists
based on MAINTAINERS, because it only be related to Virtio-vsock.
Then, first I send v2 patch based on Jason's suggestions, and then let's
see how to combine with virtio-vsock and virtio-net. What do you think?
Thanks,
Yiwen.
>
>> In addition, multiqueue feature I have not implemented it yet.
>>
>> Thanks,
>> Yiwen.
>>
>
>
>
>
> .
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [tip:core/rcu] drivers/vhost: Replace synchronize_rcu_bh() with synchronize_rcu()
From: tip-bot for Paul E. McKenney @ 2018-12-04 22:39 UTC (permalink / raw)
To: linux-tip-commits
Cc: kvm, mst, netdev, virtualization, hpa, tglx, paulmck, mingo
Commit-ID: d05faa5f1ac50beef77b4ceba0e8e157d41146e2
Gitweb: https://git.kernel.org/tip/d05faa5f1ac50beef77b4ceba0e8e157d41146e2
Author: Paul E. McKenney <paulmck@linux.ibm.com>
AuthorDate: Mon, 5 Nov 2018 17:14:53 -0800
Committer: Paul E. McKenney <paulmck@linux.ibm.com>
CommitDate: Tue, 27 Nov 2018 09:21:37 -0800
drivers/vhost: Replace synchronize_rcu_bh() with synchronize_rcu()
Now that synchronize_rcu() waits for bh-disable regions of code as well
as RCU read-side critical sections, synchronize_rcu_bh() can be replaced
by synchronize_rcu(). This commit therefore makes this change.
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: <kvm@vger.kernel.org>
Cc: <virtualization@lists.linux-foundation.org>
Cc: <netdev@vger.kernel.org>
---
drivers/vhost/net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index ab11b2bee273..564ead864028 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1359,7 +1359,7 @@ static int vhost_net_release(struct inode *inode, struct file *f)
if (rx_sock)
sockfd_put(rx_sock);
/* Make sure no callbacks are outstanding */
- synchronize_rcu_bh();
+ synchronize_rcu();
/* We do an extra flush before freeing memory,
* since jobs can re-queue themselves. */
vhost_net_flush(n);
^ permalink raw reply related
* RE: [PATCH v9] virtio_blk: add discard and write zeroes support
From: Liu, Changpeng @ 2018-12-05 9:46 UTC (permalink / raw)
To: Stefan Hajnoczi, Daniel Verkamp
Cc: Jens Axboe, Christoph Hellwig, Michael S. Tsirkin,
virtualization@lists.linux-foundation.org,
linux-block@vger.kernel.org, Paolo Bonzini
In-Reply-To: <20181102041751.GA13688@stefanha-x1.localdomain>
What's the status of this patch ? anybody pulled it for the branch ?
> -----Original Message-----
> From: Stefan Hajnoczi [mailto:stefanha@redhat.com]
> Sent: Friday, November 2, 2018 12:18 PM
> To: Daniel Verkamp <dverkamp@chromium.org>
> Cc: virtualization@lists.linux-foundation.org; linux-block@vger.kernel.org;
> Michael S. Tsirkin <mst@redhat.com>; Jason Wang <jasowang@redhat.com>;
> Jens Axboe <axboe@kernel.dk>; Paolo Bonzini <pbonzini@redhat.com>;
> Christoph Hellwig <hch@infradead.org>; Liu, Changpeng
> <changpeng.liu@intel.com>
> Subject: Re: [PATCH v9] virtio_blk: add discard and write zeroes support
>
> On Thu, Nov 01, 2018 at 03:40:35PM -0700, Daniel Verkamp wrote:
> > From: Changpeng Liu <changpeng.liu@intel.com>
> >
> > In commit 88c85538, "virtio-blk: add discard and write zeroes features
> > to specification" (https://github.com/oasis-tcs/virtio-spec), the virtio
> > block specification has been extended to add VIRTIO_BLK_T_DISCARD and
> > VIRTIO_BLK_T_WRITE_ZEROES commands. This patch enables support for
> > discard and write zeroes in the virtio-blk driver when the device
> > advertises the corresponding features, VIRTIO_BLK_F_DISCARD and
> > VIRTIO_BLK_F_WRITE_ZEROES.
> >
> > Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
> > Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
> > ---
> > dverkamp: I've picked up this patch and made a few minor changes (as
> > listed below); most notably, I changed the kmalloc back to GFP_ATOMIC,
> > since it can be called from a context where sleeping is not allowed.
> > To prevent large allocations, I've also clamped the maximum number of
> > discard segments to 256; this results in a 4K allocation and should be
> > plenty of descriptors for most use cases.
> >
> > I also removed most of the description from the commit message, since it
> > was duplicating the comments from virtio_blk.h and quoting parts of the
> > spec without adding any extra information. I have tested this iteration
> > of the patch using crosvm with modifications to enable the new features:
> > https://chromium.googlesource.com/chromiumos/platform/crosvm/
> >
> > v9 fixes a number of review issues; I didn't attempt to optimize the
> > single-element write zeroes case, so it still does an allocation per
> > request (I did not see any easy place to put the payload that would
> > avoid the allocation).
> >
> > CHANGELOG:
> > v9: [dverkamp] fix LE types in discard struct; cleanups from Ming Lei
> > v8: [dverkamp] replace shifts by 9 with SECTOR_SHIFT constant
> > v7: [dverkamp] use GFP_ATOMIC for allocation that may not sleep; clarify
> > descriptor flags field; comment wording cleanups.
> > v6: don't set T_OUT bit to discard and write zeroes commands.
> > v5: use new block layer API: blk_queue_flag_set.
> > v4: several optimizations based on MST's comments, remove bit field
> > usage for command descriptor.
> > v3: define the virtio-blk protocol to add discard and write zeroes
> > support, first version implementation based on proposed specification.
> > v2: add write zeroes command support.
> > v1: initial proposal implementation for discard command.
> > ---
> > drivers/block/virtio_blk.c | 83 ++++++++++++++++++++++++++++++++-
> > include/uapi/linux/virtio_blk.h | 54 +++++++++++++++++++++
> > 2 files changed, 135 insertions(+), 2 deletions(-)
>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
^ permalink raw reply
* [PATCH 1/3] drm/virtio: log error responses
From: Gerd Hoffmann @ 2018-12-05 10:53 UTC (permalink / raw)
To: dri-devel, David Airlie
Cc: David Airlie, open list, open list:VIRTIO GPU DRIVER
In-Reply-To: <20181205105317.15138-1-kraxel@redhat.com>
If we got an error response code from the host, print it to the log.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index e27c4aedb8..6bc2008b0d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -192,8 +192,16 @@ void virtio_gpu_dequeue_ctrl_func(struct work_struct *work)
list_for_each_entry_safe(entry, tmp, &reclaim_list, list) {
resp = (struct virtio_gpu_ctrl_hdr *)entry->resp_buf;
- if (resp->type != cpu_to_le32(VIRTIO_GPU_RESP_OK_NODATA))
- DRM_DEBUG("response 0x%x\n", le32_to_cpu(resp->type));
+ if (resp->type != cpu_to_le32(VIRTIO_GPU_RESP_OK_NODATA)) {
+ if (resp->type >= cpu_to_le32(VIRTIO_GPU_RESP_ERR_UNSPEC)) {
+ struct virtio_gpu_ctrl_hdr *cmd;
+ cmd = (struct virtio_gpu_ctrl_hdr *)entry->buf;
+ DRM_ERROR("response 0x%x (command 0x%x)\n",
+ le32_to_cpu(resp->type),
+ le32_to_cpu(cmd->type));
+ } else
+ DRM_DEBUG("response 0x%x\n", le32_to_cpu(resp->type));
+ }
if (resp->flags & cpu_to_le32(VIRTIO_GPU_FLAG_FENCE)) {
u64 f = le64_to_cpu(resp->fence_id);
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] drm/virtio: fix pageflip flush
From: Gerd Hoffmann @ 2018-12-05 10:53 UTC (permalink / raw)
To: dri-devel, David Airlie
Cc: David Airlie, open list, open list:VIRTIO GPU DRIVER
In-Reply-To: <20181205105317.15138-1-kraxel@redhat.com>
Sending the flush command only makes sense if we actually have
a framebuffer attached to the scanout (handle != 0).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c
index ead5c53d4e..548265b8e8 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -130,11 +130,12 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
plane->state->src_h >> 16,
plane->state->src_x >> 16,
plane->state->src_y >> 16);
- virtio_gpu_cmd_resource_flush(vgdev, handle,
- plane->state->src_x >> 16,
- plane->state->src_y >> 16,
- plane->state->src_w >> 16,
- plane->state->src_h >> 16);
+ if (handle)
+ virtio_gpu_cmd_resource_flush(vgdev, handle,
+ plane->state->src_x >> 16,
+ plane->state->src_y >> 16,
+ plane->state->src_w >> 16,
+ plane->state->src_h >> 16);
}
static int virtio_gpu_cursor_prepare_fb(struct drm_plane *plane,
--
2.9.3
^ permalink raw reply related
* [PATCH 3/3] drm/virtio: drop virtio_gpu_fence_cleanup()
From: Gerd Hoffmann @ 2018-12-05 10:53 UTC (permalink / raw)
To: dri-devel, David Airlie
Cc: David Airlie, open list, open list:VIRTIO GPU DRIVER
In-Reply-To: <20181205105317.15138-1-kraxel@redhat.com>
Just call drm_fence_put directly instead.
Also set vgfb->fence to NULL after dropping the reference.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 -
drivers/gpu/drm/virtio/virtgpu_fence.c | 8 --------
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_plane.c | 6 ++++--
4 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 1deb41d42e..551860497f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -351,7 +351,6 @@ int virtio_gpu_mmap(struct file *filp, struct vm_area_struct *vma);
/* virtio_gpu_fence.c */
struct virtio_gpu_fence *virtio_gpu_fence_alloc(
struct virtio_gpu_device *vgdev);
-void virtio_gpu_fence_cleanup(struct virtio_gpu_fence *fence);
int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
struct virtio_gpu_ctrl_hdr *cmd_hdr,
struct virtio_gpu_fence *fence);
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 4d6826b278..21bd4c4a32 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -81,14 +81,6 @@ struct virtio_gpu_fence *virtio_gpu_fence_alloc(struct virtio_gpu_device *vgdev)
return fence;
}
-void virtio_gpu_fence_cleanup(struct virtio_gpu_fence *fence)
-{
- if (!fence)
- return;
-
- dma_fence_put(&fence->f);
-}
-
int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
struct virtio_gpu_ctrl_hdr *cmd_hdr,
struct virtio_gpu_fence *fence)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 161b80fee4..14ce8188c0 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -351,7 +351,7 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
virtio_gpu_cmd_resource_create_3d(vgdev, qobj, &rc_3d);
ret = virtio_gpu_object_attach(vgdev, qobj, fence);
if (ret) {
- virtio_gpu_fence_cleanup(fence);
+ dma_fence_put(&fence->f);
goto fail_backoff;
}
ttm_eu_fence_buffer_objects(&ticket, &validate_list, &fence->f);
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 548265b8e8..024c2aa0c9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -169,8 +169,10 @@ static void virtio_gpu_cursor_cleanup_fb(struct drm_plane *plane,
return;
vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
- if (vgfb->fence)
- virtio_gpu_fence_cleanup(vgfb->fence);
+ if (vgfb->fence) {
+ dma_fence_put(&vgfb->fence->f);
+ vgfb->fence = NULL;
+ }
}
static void virtio_gpu_cursor_plane_update(struct drm_plane *plane,
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v9] virtio_blk: add discard and write zeroes support
From: Michael S. Tsirkin @ 2018-12-05 13:41 UTC (permalink / raw)
To: Liu, Changpeng
Cc: Jens Axboe, Christoph Hellwig,
virtualization@lists.linux-foundation.org,
linux-block@vger.kernel.org, Stefan Hajnoczi, Paolo Bonzini
In-Reply-To: <FF7FC980937D6342B9D289F5F3C7C2625B7817C5@SHSMSX103.ccr.corp.intel.com>
On Wed, Dec 05, 2018 at 09:46:16AM +0000, Liu, Changpeng wrote:
> What's the status of this patch ? anybody pulled it for the branch ?
I will merge it for next.
>
> > -----Original Message-----
> > From: Stefan Hajnoczi [mailto:stefanha@redhat.com]
> > Sent: Friday, November 2, 2018 12:18 PM
> > To: Daniel Verkamp <dverkamp@chromium.org>
> > Cc: virtualization@lists.linux-foundation.org; linux-block@vger.kernel.org;
> > Michael S. Tsirkin <mst@redhat.com>; Jason Wang <jasowang@redhat.com>;
> > Jens Axboe <axboe@kernel.dk>; Paolo Bonzini <pbonzini@redhat.com>;
> > Christoph Hellwig <hch@infradead.org>; Liu, Changpeng
> > <changpeng.liu@intel.com>
> > Subject: Re: [PATCH v9] virtio_blk: add discard and write zeroes support
> >
> > On Thu, Nov 01, 2018 at 03:40:35PM -0700, Daniel Verkamp wrote:
> > > From: Changpeng Liu <changpeng.liu@intel.com>
> > >
> > > In commit 88c85538, "virtio-blk: add discard and write zeroes features
> > > to specification" (https://github.com/oasis-tcs/virtio-spec), the virtio
> > > block specification has been extended to add VIRTIO_BLK_T_DISCARD and
> > > VIRTIO_BLK_T_WRITE_ZEROES commands. This patch enables support for
> > > discard and write zeroes in the virtio-blk driver when the device
> > > advertises the corresponding features, VIRTIO_BLK_F_DISCARD and
> > > VIRTIO_BLK_F_WRITE_ZEROES.
> > >
> > > Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
> > > Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
> > > ---
> > > dverkamp: I've picked up this patch and made a few minor changes (as
> > > listed below); most notably, I changed the kmalloc back to GFP_ATOMIC,
> > > since it can be called from a context where sleeping is not allowed.
> > > To prevent large allocations, I've also clamped the maximum number of
> > > discard segments to 256; this results in a 4K allocation and should be
> > > plenty of descriptors for most use cases.
> > >
> > > I also removed most of the description from the commit message, since it
> > > was duplicating the comments from virtio_blk.h and quoting parts of the
> > > spec without adding any extra information. I have tested this iteration
> > > of the patch using crosvm with modifications to enable the new features:
> > > https://chromium.googlesource.com/chromiumos/platform/crosvm/
> > >
> > > v9 fixes a number of review issues; I didn't attempt to optimize the
> > > single-element write zeroes case, so it still does an allocation per
> > > request (I did not see any easy place to put the payload that would
> > > avoid the allocation).
> > >
> > > CHANGELOG:
> > > v9: [dverkamp] fix LE types in discard struct; cleanups from Ming Lei
> > > v8: [dverkamp] replace shifts by 9 with SECTOR_SHIFT constant
> > > v7: [dverkamp] use GFP_ATOMIC for allocation that may not sleep; clarify
> > > descriptor flags field; comment wording cleanups.
> > > v6: don't set T_OUT bit to discard and write zeroes commands.
> > > v5: use new block layer API: blk_queue_flag_set.
> > > v4: several optimizations based on MST's comments, remove bit field
> > > usage for command descriptor.
> > > v3: define the virtio-blk protocol to add discard and write zeroes
> > > support, first version implementation based on proposed specification.
> > > v2: add write zeroes command support.
> > > v1: initial proposal implementation for discard command.
> > > ---
> > > drivers/block/virtio_blk.c | 83 ++++++++++++++++++++++++++++++++-
> > > include/uapi/linux/virtio_blk.h | 54 +++++++++++++++++++++
> > > 2 files changed, 135 insertions(+), 2 deletions(-)
> >
> > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
^ permalink raw reply
* Call for Papers - MICRADS 2019, Rio de Janeiro, Brazil | Deadline: December 28
From: Maria @ 2018-12-05 16:58 UTC (permalink / raw)
To: virtualization
[-- Attachment #1.1: Type: text/plain, Size: 5881 bytes --]
***** Proceedings by Springer
--------------------------------------
MICRADS´19 - The 2019 Multidisciplinary International Conference of Research Applied to Defense and Security
Rio de Janeiro, Brazil, 8 - 10 May 2019
http://www.micrads.org/ <http://www.micrads.org/>
------------------------------------------------------------------------------------------------------------------------------
Scope
MICRADS´19 - The 2019 Multidisciplinary International Conference of Research Applied to Defense and Security, to be held at Rio de Janeiro, Brazil, 8 - 10 May 2019, is an international forum for researchers and practitioners to present and discuss the most recent innovations, trends, results, experiences and concerns in the several perspectives of Defense and Security.
We are pleased to invite you to submit your papers to MICRADS´19. They can be written in English, Spanish or Portuguese. All submissions will be reviewed on the basis of relevance, originality, importance and clarity.
Topics
Submitted papers should be related with one or more of the main themes proposed for the Conference:
Area A: Systems, Communication and Defense
A1) Information and Communication Technology in Education
A2) Simulation and computer vision in military applications
A3) Analysis and Signal Processing
A4) Cybersecurity and Cyberdefense
A5) Computer Networks, Mobility and Pervasive Systems
Area B: Strategy and political-administrative vision in Defense
B1) Safety and Maritime Protection
B2) Strategy, Geopolitics and Oceanopolitics
B3) Planning, economy and logistics applied to Defense
B4) Leadership and e-leadership
B5) Military Marketing
B6) Health informatics in military applications
Area C: Engineering and technologies applied to Defense
C1) Wearable Technology and Assistance Devices
C2) Military Naval Engineering
C3) Weapons and Combat Systems
C4) Chemical, Biological and Nuclear Defense
C5) Defense Engineering (General)
Submission and Decision
Submitted papers written in English (until 10-page limit) must comply with the format of Smart Innovation, Systems and Technologies series (see Instructions for Authors at Springer Website <https://www.springer.com/us/authors-editors/conference-proceedings/conference-proceedings-guidelines>), must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors’ identification. Therefore, the authors’ names, affiliations and e-mails should not be included in the version for evaluation by the Scientific Committee. This information should only be included in the camera-ready version, saved in Word or Latex format and also in PDF format. These files must be accompanied by the Consent to Publish form <http://www.micrads.org/consent.doc> filled out, in a ZIP file, and uploaded at the conference management system.
Submitted papers written in Spanish or Portuguese (until 15-page limit) must comply with the format of RISTI <http://www.risti.xyz/> - Revista Ibérica de Sistemas e Tecnologias de Informação (download instructions/template for authors in Spanish <http://www.risti.xyz/formato-es.doc> or Portuguese <http://www.risti.xyz/formato-pt.doc>), must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors’ identification. Therefore, the authors’ names, affiliations and e-mails should not be included in the version for evaluation by the Scientific Committee. This information should only be included in the camera-ready version, saved in Word. These file must be uploaded at the conference management system in a ZIP file.
All papers will be subjected to a “blind review” by at least two members of the Scientific Committee.
Based on Scientific Committee evaluation, a paper can be rejected or accepted by the Conference Chairs. In the later case, it can be accepted as paper or poster.
The authors of papers accepted as posters must build and print a poster to be exhibited during the Conference. This poster must follow an A1 or A2 vertical format. The Conference can includes Work Sessions where these posters are presented and orally discussed, with a 7 minute limit per poster.
The authors of accepted papers will have 15 minutes to present their work in a Conference Work Session; approximately 5 minutes of discussion will follow each presentation.
Publication and Indexing
To ensure that an accepted paper is published, at least one of the authors must be fully registered by the 11 of February 2019, and the paper must comply with the suggested layout and page-limit (until 10 pages). Additionally, all recommended changes must be addressed by the authors before they submit the camera-ready version.
No more than one paper per registration will be published. An extra fee must be paid for publication of additional papers, with a maximum of one additional paper per registration. One registration permits only the participation of one author in the conference.
Papers can be written in English, Spanish or Portuguese. Accepted and registered papers written in English will be published in Proceedings by Springer, in a book of its SIST series, and will be submitted for indexing by ISI, SCOPUS, EI-Compendex, SpringerLink, and Google Scholar.
Important Dates
Paper Submission: December 28, 2018
Notification of Acceptance: January 28, 2019
Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: February 11, 2019.
Camera-ready Submission: February 11, 2019
Website of MICRADS'19: http://www.micrads.org/ <http://www.micrads.org/>
---
This email has been checked for viruses by AVG.
https://www.avg.com
[-- Attachment #1.2: Type: text/html, Size: 8900 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH RFC 0/2] virtio-net: interrupt related improvements
From: Michael S. Tsirkin @ 2018-12-05 22:54 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, virtualization, maxime.coquelin, wexu
Now that we have brought the virtio overhead way down with a fast packed
ring implementation, we seem to be actually observing TCP drops
indicative of bufferbloat. So let's try to enable TSQ. Note: it isn't
clear that the default pacing is great for the virt usecase. It's worth
trying to play with sk_pacing_shift_update to see what happens.
For this reason, and for a more important one that I didn't
have time to test it yet, sending as an RFC.
Michael S. Tsirkin (2):
virtio-net: bql support
virtio_net: bulk free tx skbs
drivers/net/virtio_net.c | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)
--
MST
^ permalink raw reply
* [PATCH RFC 1/2] virtio-net: bql support
From: Michael S. Tsirkin @ 2018-12-05 22:54 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, virtualization, maxime.coquelin, wexu, David S. Miller
In-Reply-To: <20181205225323.12555-1-mst@redhat.com>
When use_napi is set, let's enable BQLs. Note: some of the issues are
similar to wifi. It's worth considering whether something similar to
commit 36148c2bbfbe ("mac80211: Adjust TSQ pacing shift") might be
benefitial.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/virtio_net.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cecfd77c9f3c..b657bde6b94b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1325,7 +1325,8 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
return stats.packets;
}
-static void free_old_xmit_skbs(struct send_queue *sq)
+static void free_old_xmit_skbs(struct send_queue *sq, struct netdev_queue *txq,
+ bool use_napi)
{
struct sk_buff *skb;
unsigned int len;
@@ -1347,6 +1348,9 @@ static void free_old_xmit_skbs(struct send_queue *sq)
if (!packets)
return;
+ if (use_napi)
+ netdev_tx_completed_queue(txq, packets, bytes);
+
u64_stats_update_begin(&sq->stats.syncp);
sq->stats.bytes += bytes;
sq->stats.packets += packets;
@@ -1364,7 +1368,7 @@ static void virtnet_poll_cleantx(struct receive_queue *rq)
return;
if (__netif_tx_trylock(txq)) {
- free_old_xmit_skbs(sq);
+ free_old_xmit_skbs(sq, txq, true);
__netif_tx_unlock(txq);
}
@@ -1440,7 +1444,7 @@ static int virtnet_poll_tx(struct napi_struct *napi, int budget)
struct netdev_queue *txq = netdev_get_tx_queue(vi->dev, vq2txq(sq->vq));
__netif_tx_lock(txq, raw_smp_processor_id());
- free_old_xmit_skbs(sq);
+ free_old_xmit_skbs(sq, txq, true);
__netif_tx_unlock(txq);
virtqueue_napi_complete(napi, sq->vq, 0);
@@ -1505,13 +1509,15 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
struct send_queue *sq = &vi->sq[qnum];
int err;
struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
- bool kick = !skb->xmit_more;
+ bool more = skb->xmit_more;
bool use_napi = sq->napi.weight;
+ unsigned int bytes = skb->len;
+ bool kick;
/* Free up any pending old buffers before queueing new ones. */
- free_old_xmit_skbs(sq);
+ free_old_xmit_skbs(sq, txq, use_napi);
- if (use_napi && kick)
+ if (use_napi && !more)
virtqueue_enable_cb_delayed(sq->vq);
/* timestamp packet in software */
@@ -1552,7 +1558,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
if (!use_napi &&
unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
/* More just got used, free them then recheck. */
- free_old_xmit_skbs(sq);
+ free_old_xmit_skbs(sq, txq, false);
if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
netif_start_subqueue(dev, qnum);
virtqueue_disable_cb(sq->vq);
@@ -1560,7 +1566,12 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
}
}
- if (kick || netif_xmit_stopped(txq)) {
+ if (use_napi)
+ kick = __netdev_tx_sent_queue(txq, bytes, more);
+ else
+ kick = !more || netif_xmit_stopped(txq);
+
+ if (kick) {
if (virtqueue_kick_prepare(sq->vq) && virtqueue_notify(sq->vq)) {
u64_stats_update_begin(&sq->stats.syncp);
sq->stats.kicks++;
--
MST
^ permalink raw reply related
* [PATCH RFC 2/2] virtio_net: bulk free tx skbs
From: Michael S. Tsirkin @ 2018-12-05 22:54 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, virtualization, maxime.coquelin, wexu, David S. Miller
In-Reply-To: <20181205225323.12555-1-mst@redhat.com>
Use napi_consume_skb() to get bulk free. Note that napi_consume_skb is
safe to call in a non-napi context as long as the napi_budget flag is
correct.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b657bde6b94b..18c06322be40 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1339,7 +1339,7 @@ static void free_old_xmit_skbs(struct send_queue *sq, struct netdev_queue *txq,
bytes += skb->len;
packets++;
- dev_consume_skb_any(skb);
+ napi_consume_skb(skb, use_napi);
}
/* Avoid overhead when no packets have been processed
--
MST
^ permalink raw reply related
* Re: [PATCH RFC 1/2] virtio-net: bql support
From: Jason Wang @ 2018-12-06 8:17 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: netdev, virtualization, maxime.coquelin, wexu, David S. Miller
In-Reply-To: <20181205225323.12555-2-mst@redhat.com>
On 2018/12/6 上午6:54, Michael S. Tsirkin wrote:
> When use_napi is set, let's enable BQLs. Note: some of the issues are
> similar to wifi. It's worth considering whether something similar to
> commit 36148c2bbfbe ("mac80211: Adjust TSQ pacing shift") might be
> benefitial.
I've played a similar patch several days before. The tricky part is the
mode switching between napi and no napi. We should make sure when the
packet is sent and trakced by BQL, it should be consumed by BQL as
well. I did it by tracking it through skb->cb. And deal with the freeze
by reset the BQL status. Patch attached.
But when testing with vhost-net, I don't very a stable performance, it
was probably because we batch the used ring updating so tx interrupt may
come randomly. We probably need to implement time bounded coalescing
mechanism which could be configured from userspace.
Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR
regression on machine without APICv, (haven't found time to test APICv
machine). But consider it was for correctness, I think it's acceptable?
Then we can do optimization on top?
Thanks
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/virtio_net.c | 27 +++++++++++++++++++--------
> 1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index cecfd77c9f3c..b657bde6b94b 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1325,7 +1325,8 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
> return stats.packets;
> }
>
> -static void free_old_xmit_skbs(struct send_queue *sq)
> +static void free_old_xmit_skbs(struct send_queue *sq, struct netdev_queue *txq,
> + bool use_napi)
> {
> struct sk_buff *skb;
> unsigned int len;
> @@ -1347,6 +1348,9 @@ static void free_old_xmit_skbs(struct send_queue *sq)
> if (!packets)
> return;
>
> + if (use_napi)
> + netdev_tx_completed_queue(txq, packets, bytes);
> +
> u64_stats_update_begin(&sq->stats.syncp);
> sq->stats.bytes += bytes;
> sq->stats.packets += packets;
> @@ -1364,7 +1368,7 @@ static void virtnet_poll_cleantx(struct receive_queue *rq)
> return;
>
> if (__netif_tx_trylock(txq)) {
> - free_old_xmit_skbs(sq);
> + free_old_xmit_skbs(sq, txq, true);
> __netif_tx_unlock(txq);
> }
>
> @@ -1440,7 +1444,7 @@ static int virtnet_poll_tx(struct napi_struct *napi, int budget)
> struct netdev_queue *txq = netdev_get_tx_queue(vi->dev, vq2txq(sq->vq));
>
> __netif_tx_lock(txq, raw_smp_processor_id());
> - free_old_xmit_skbs(sq);
> + free_old_xmit_skbs(sq, txq, true);
> __netif_tx_unlock(txq);
>
> virtqueue_napi_complete(napi, sq->vq, 0);
> @@ -1505,13 +1509,15 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
> struct send_queue *sq = &vi->sq[qnum];
> int err;
> struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
> - bool kick = !skb->xmit_more;
> + bool more = skb->xmit_more;
> bool use_napi = sq->napi.weight;
> + unsigned int bytes = skb->len;
> + bool kick;
>
> /* Free up any pending old buffers before queueing new ones. */
> - free_old_xmit_skbs(sq);
> + free_old_xmit_skbs(sq, txq, use_napi);
>
> - if (use_napi && kick)
> + if (use_napi && !more)
> virtqueue_enable_cb_delayed(sq->vq);
>
> /* timestamp packet in software */
> @@ -1552,7 +1558,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
> if (!use_napi &&
> unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
> /* More just got used, free them then recheck. */
> - free_old_xmit_skbs(sq);
> + free_old_xmit_skbs(sq, txq, false);
> if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
> netif_start_subqueue(dev, qnum);
> virtqueue_disable_cb(sq->vq);
> @@ -1560,7 +1566,12 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
> }
> }
>
> - if (kick || netif_xmit_stopped(txq)) {
> + if (use_napi)
> + kick = __netdev_tx_sent_queue(txq, bytes, more);
> + else
> + kick = !more || netif_xmit_stopped(txq);
> +
> + if (kick) {
> if (virtqueue_kick_prepare(sq->vq) && virtqueue_notify(sq->vq)) {
> u64_stats_update_begin(&sq->stats.syncp);
> sq->stats.kicks++;
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH RFC 1/2] virtio-net: bql support
From: Jason Wang @ 2018-12-06 8:31 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: netdev, maxime.coquelin, David S. Miller, wexu, virtualization
In-Reply-To: <21384cb5-99a6-7431-1039-b356521e1bc3@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 5396 bytes --]
On 2018/12/6 下午4:17, Jason Wang wrote:
>
> On 2018/12/6 上午6:54, Michael S. Tsirkin wrote:
>> When use_napi is set, let's enable BQLs. Note: some of the issues are
>> similar to wifi. It's worth considering whether something similar to
>> commit 36148c2bbfbe ("mac80211: Adjust TSQ pacing shift") might be
>> benefitial.
>
>
> I've played a similar patch several days before. The tricky part is
> the mode switching between napi and no napi. We should make sure when
> the packet is sent and trakced by BQL, it should be consumed by BQL
> as well. I did it by tracking it through skb->cb. And deal with the
> freeze by reset the BQL status. Patch attached.
Add the patch.
Thanks
>
> But when testing with vhost-net, I don't very a stable performance, it
> was probably because we batch the used ring updating so tx interrupt
> may come randomly. We probably need to implement time bounded
> coalescing mechanism which could be configured from userspace.
>
> Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR
> regression on machine without APICv, (haven't found time to test APICv
> machine). But consider it was for correctness, I think it's
> acceptable? Then we can do optimization on top?
>
>
> Thanks
>
>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> ---
>> drivers/net/virtio_net.c | 27 +++++++++++++++++++--------
>> 1 file changed, 19 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index cecfd77c9f3c..b657bde6b94b 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -1325,7 +1325,8 @@ static int virtnet_receive(struct receive_queue
>> *rq, int budget,
>> return stats.packets;
>> }
>> -static void free_old_xmit_skbs(struct send_queue *sq)
>> +static void free_old_xmit_skbs(struct send_queue *sq, struct
>> netdev_queue *txq,
>> + bool use_napi)
>> {
>> struct sk_buff *skb;
>> unsigned int len;
>> @@ -1347,6 +1348,9 @@ static void free_old_xmit_skbs(struct
>> send_queue *sq)
>> if (!packets)
>> return;
>> + if (use_napi)
>> + netdev_tx_completed_queue(txq, packets, bytes);
>> +
>> u64_stats_update_begin(&sq->stats.syncp);
>> sq->stats.bytes += bytes;
>> sq->stats.packets += packets;
>> @@ -1364,7 +1368,7 @@ static void virtnet_poll_cleantx(struct
>> receive_queue *rq)
>> return;
>> if (__netif_tx_trylock(txq)) {
>> - free_old_xmit_skbs(sq);
>> + free_old_xmit_skbs(sq, txq, true);
>> __netif_tx_unlock(txq);
>> }
>> @@ -1440,7 +1444,7 @@ static int virtnet_poll_tx(struct napi_struct
>> *napi, int budget)
>> struct netdev_queue *txq = netdev_get_tx_queue(vi->dev,
>> vq2txq(sq->vq));
>> __netif_tx_lock(txq, raw_smp_processor_id());
>> - free_old_xmit_skbs(sq);
>> + free_old_xmit_skbs(sq, txq, true);
>> __netif_tx_unlock(txq);
>> virtqueue_napi_complete(napi, sq->vq, 0);
>> @@ -1505,13 +1509,15 @@ static netdev_tx_t start_xmit(struct sk_buff
>> *skb, struct net_device *dev)
>> struct send_queue *sq = &vi->sq[qnum];
>> int err;
>> struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
>> - bool kick = !skb->xmit_more;
>> + bool more = skb->xmit_more;
>> bool use_napi = sq->napi.weight;
>> + unsigned int bytes = skb->len;
>> + bool kick;
>> /* Free up any pending old buffers before queueing new ones. */
>> - free_old_xmit_skbs(sq);
>> + free_old_xmit_skbs(sq, txq, use_napi);
>> - if (use_napi && kick)
>> + if (use_napi && !more)
>> virtqueue_enable_cb_delayed(sq->vq);
>> /* timestamp packet in software */
>> @@ -1552,7 +1558,7 @@ static netdev_tx_t start_xmit(struct sk_buff
>> *skb, struct net_device *dev)
>> if (!use_napi &&
>> unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
>> /* More just got used, free them then recheck. */
>> - free_old_xmit_skbs(sq);
>> + free_old_xmit_skbs(sq, txq, false);
>> if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
>> netif_start_subqueue(dev, qnum);
>> virtqueue_disable_cb(sq->vq);
>> @@ -1560,7 +1566,12 @@ static netdev_tx_t start_xmit(struct sk_buff
>> *skb, struct net_device *dev)
>> }
>> }
>> - if (kick || netif_xmit_stopped(txq)) {
>> + if (use_napi)
>> + kick = __netdev_tx_sent_queue(txq, bytes, more);
>> + else
>> + kick = !more || netif_xmit_stopped(txq);
>> +
>> + if (kick) {
>> if (virtqueue_kick_prepare(sq->vq) &&
>> virtqueue_notify(sq->vq)) {
>> u64_stats_update_begin(&sq->stats.syncp);
>> sq->stats.kicks++;
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[-- Attachment #2: 0001-virtio-net-byte-queue-limit-support.patch --]
[-- Type: text/x-patch, Size: 4777 bytes --]
From f1c27543dc412778e682b63addbb0a471afc5153 Mon Sep 17 00:00:00 2001
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 20 Nov 2018 14:25:30 +0800
Subject: [PATCH] virtio-net: byte queue limit support
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/virtio_net.c | 46 ++++++++++++++++++++++++++++++++++++++--------
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 47979fc..8712c11 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -279,6 +279,14 @@ static inline struct virtio_net_hdr_mrg_rxbuf *skb_vnet_hdr(struct sk_buff *skb)
return (struct virtio_net_hdr_mrg_rxbuf *)skb->cb;
}
+
+static inline int *skb_cb_bql(struct sk_buff *skb)
+{
+ BUILD_BUG_ON(sizeof(struct virtio_net_hdr_mrg_rxbuf) +
+ sizeof(int) > sizeof(skb->cb));
+ return (int *)(skb->cb + sizeof(struct virtio_net_hdr_mrg_rxbuf));
+}
+
/*
* private is used to chain pages for big packets, put the whole
* most recent used list in the beginning for reuse
@@ -1325,12 +1333,14 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
return stats.packets;
}
-static void free_old_xmit_skbs(struct send_queue *sq)
+static void free_old_xmit_skbs(struct send_queue *sq,
+ struct netdev_queue *txq)
{
struct sk_buff *skb;
unsigned int len;
- unsigned int packets = 0;
- unsigned int bytes = 0;
+ unsigned int packets = 0, bql_packets = 0;
+ unsigned int bytes = 0, bql_bytes = 0;
+ int *bql;
while ((skb = virtqueue_get_buf(sq->vq, &len)) != NULL) {
pr_debug("Sent skb %p\n", skb);
@@ -1338,6 +1348,12 @@ static void free_old_xmit_skbs(struct send_queue *sq)
bytes += skb->len;
packets++;
+ bql = skb_cb_bql(skb);
+ if (*bql) {
+ bql_packets ++;
+ bql_bytes += skb->len;
+ }
+
dev_consume_skb_any(skb);
}
@@ -1351,6 +1367,8 @@ static void free_old_xmit_skbs(struct send_queue *sq)
sq->stats.bytes += bytes;
sq->stats.packets += packets;
u64_stats_update_end(&sq->stats.syncp);
+
+ netdev_tx_completed_queue(txq, bql_packets, bql_bytes);
}
static void virtnet_poll_cleantx(struct receive_queue *rq)
@@ -1364,7 +1382,7 @@ static void virtnet_poll_cleantx(struct receive_queue *rq)
return;
if (__netif_tx_trylock(txq)) {
- free_old_xmit_skbs(sq);
+ free_old_xmit_skbs(sq, txq);
__netif_tx_unlock(txq);
}
@@ -1440,7 +1458,7 @@ static int virtnet_poll_tx(struct napi_struct *napi, int budget)
struct netdev_queue *txq = netdev_get_tx_queue(vi->dev, vq2txq(sq->vq));
__netif_tx_lock(txq, raw_smp_processor_id());
- free_old_xmit_skbs(sq);
+ free_old_xmit_skbs(sq, txq);
__netif_tx_unlock(txq);
virtqueue_napi_complete(napi, sq->vq, 0);
@@ -1459,6 +1477,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
int num_sg;
unsigned hdr_len = vi->hdr_len;
bool can_push;
+ int *bql = skb_cb_bql(skb);
pr_debug("%s: xmit %p %pM\n", vi->dev->name, skb, dest);
@@ -1495,6 +1514,8 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
return num_sg;
num_sg++;
}
+
+ *bql = sq->napi.weight ? 1 : 0;
return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, GFP_ATOMIC);
}
@@ -1509,7 +1530,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
bool use_napi = sq->napi.weight;
/* Free up any pending old buffers before queueing new ones. */
- free_old_xmit_skbs(sq);
+ free_old_xmit_skbs(sq, txq);
if (use_napi && kick)
virtqueue_enable_cb_delayed(sq->vq);
@@ -1537,6 +1558,9 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
nf_reset(skb);
}
+ if (use_napi)
+ netdev_tx_sent_queue(txq, skb->len);
+
/* If running out of space, stop queue to avoid getting packets that we
* are then unable to transmit.
* An alternative would be to force queuing layer to requeue the skb by
@@ -1552,7 +1576,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
if (!use_napi &&
unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
/* More just got used, free them then recheck. */
- free_old_xmit_skbs(sq);
+ free_old_xmit_skbs(sq, txq);
if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
netif_start_subqueue(dev, qnum);
virtqueue_disable_cb(sq->vq);
@@ -2275,8 +2299,14 @@ static void virtnet_freeze_down(struct virtio_device *vdev)
if (netif_running(vi->dev)) {
for (i = 0; i < vi->max_queue_pairs; i++) {
+ struct send_queue *sq = &vi->sq[i];
+ struct netdev_queue *txq =
+ netdev_get_tx_queue(vi->dev, i);
+
napi_disable(&vi->rq[i].napi);
- virtnet_napi_tx_disable(&vi->sq[i].napi);
+ virtnet_napi_tx_disable(&sq->napi);
+ if (sq->napi.weight)
+ netdev_tx_reset_queue(txq);
}
}
}
--
1.8.3.1
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* [PATCH] drm/qxl: use qxl_num_crtc directly
From: Gerd Hoffmann @ 2018-12-06 10:33 UTC (permalink / raw)
To: dri-devel, David Airlie
Cc: David Airlie, open list:DRM DRIVER FOR QXL VIRTUAL GPU, open list,
open list:DRM DRIVER FOR QXL VIRTUAL GPU
Just use qxl_num_crtc directly everywhere instead of using
qdev->monitors_config->max_allowed. Drops pointless indirection
and also is less confusing.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/qxl/qxl_display.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
index ce0b9c40fc..6437369a31 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -80,10 +80,10 @@ static int qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
DRM_DEBUG_KMS("no client monitors configured\n");
return status;
}
- if (num_monitors > qdev->monitors_config->max_allowed) {
+ if (num_monitors > qxl_num_crtc) {
DRM_DEBUG_KMS("client monitors list will be truncated: %d < %d\n",
- qdev->monitors_config->max_allowed, num_monitors);
- num_monitors = qdev->monitors_config->max_allowed;
+ qxl_num_crtc, num_monitors);
+ num_monitors = qxl_num_crtc;
} else {
num_monitors = qdev->rom->client_monitors_config.count;
}
@@ -96,8 +96,7 @@ static int qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
return status;
}
/* we copy max from the client but it isn't used */
- qdev->client_monitors_config->max_allowed =
- qdev->monitors_config->max_allowed;
+ qdev->client_monitors_config->max_allowed = qxl_num_crtc;
for (i = 0 ; i < qdev->client_monitors_config->count ; ++i) {
struct qxl_urect *c_rect =
&qdev->rom->client_monitors_config.heads[i];
@@ -204,7 +203,7 @@ static int qxl_add_monitors_config_modes(struct drm_connector *connector,
if (!qdev->monitors_config)
return 0;
- if (h >= qdev->monitors_config->max_allowed)
+ if (h >= qxl_num_crtc)
return 0;
if (!qdev->client_monitors_config)
return 0;
@@ -307,8 +306,7 @@ static void qxl_crtc_update_monitors_config(struct drm_crtc *crtc,
return;
}
- if (!qdev->monitors_config ||
- qdev->monitors_config->max_allowed <= i)
+ if (!qdev->monitors_config || qxl_num_crtc <= i)
return;
head.id = i;
@@ -348,9 +346,10 @@ static void qxl_crtc_update_monitors_config(struct drm_crtc *crtc,
if (oldcount != qdev->monitors_config->count)
DRM_DEBUG_KMS("active heads %d -> %d (%d total)\n",
oldcount, qdev->monitors_config->count,
- qdev->monitors_config->max_allowed);
+ qxl_num_crtc);
qdev->monitors_config->heads[i] = head;
+ qdev->monitors_config->max_allowed = qxl_num_crtc;
qxl_send_monitors_config(qdev);
}
@@ -1097,9 +1096,8 @@ int qxl_create_monitors_object(struct qxl_device *qdev)
{
int ret;
struct drm_gem_object *gobj;
- int max_allowed = qxl_num_crtc;
int monitors_config_size = sizeof(struct qxl_monitors_config) +
- max_allowed * sizeof(struct qxl_head);
+ qxl_num_crtc * sizeof(struct qxl_head);
ret = qxl_gem_object_create(qdev, monitors_config_size, 0,
QXL_GEM_DOMAIN_VRAM,
@@ -1121,7 +1119,6 @@ int qxl_create_monitors_object(struct qxl_device *qdev)
qxl_bo_physical_address(qdev, qdev->monitors_config_bo, 0);
memset(qdev->monitors_config, 0, monitors_config_size);
- qdev->monitors_config->max_allowed = max_allowed;
return 0;
}
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] drm/qxl: allow both PRIV and VRAM placement for QXL_GEM_DOMAIN_SURFACE
From: Gerd Hoffmann @ 2018-12-06 10:46 UTC (permalink / raw)
To: dri-devel, David Airlie
Cc: David Airlie, open list:DRM DRIVER FOR QXL VIRTUAL GPU, open list,
open list:DRM DRIVER FOR QXL VIRTUAL GPU
In-Reply-To: <20181206104638.23330-1-kraxel@redhat.com>
qxl surfaces (used for framebuffers and gem objects) can live in both
VRAM and PRIV ttm domains. Update placement setup to include both. Put
PRIV first in the list so it is preferred, so VRAM will have more room
for objects which must be allocated there.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/qxl/qxl_object.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index 91f3bbc73e..f7f9f4f4fe 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -58,10 +58,10 @@ void qxl_ttm_placement_from_domain(struct qxl_bo *qbo, u32 domain, bool pinned)
qbo->placement.placement = qbo->placements;
qbo->placement.busy_placement = qbo->placements;
- if (domain == QXL_GEM_DOMAIN_VRAM)
- qbo->placements[c++].flags = TTM_PL_FLAG_CACHED | TTM_PL_FLAG_VRAM | pflag;
if (domain == QXL_GEM_DOMAIN_SURFACE)
qbo->placements[c++].flags = TTM_PL_FLAG_CACHED | TTM_PL_FLAG_PRIV | pflag;
+ if (domain == QXL_GEM_DOMAIN_SURFACE || domain == QXL_GEM_DOMAIN_VRAM)
+ qbo->placements[c++].flags = TTM_PL_FLAG_CACHED | TTM_PL_FLAG_VRAM | pflag;
if (domain == QXL_GEM_DOMAIN_CPU)
qbo->placements[c++].flags = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM | pflag;
if (!c)
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] drm/qxl: use QXL_GEM_DOMAIN_SURFACE for shadow bo.
From: Gerd Hoffmann @ 2018-12-06 10:46 UTC (permalink / raw)
To: dri-devel, David Airlie
Cc: David Airlie, open list:DRM DRIVER FOR QXL VIRTUAL GPU, open list,
open list:DRM DRIVER FOR QXL VIRTUAL GPU
In-Reply-To: <20181206104638.23330-1-kraxel@redhat.com>
The shadow bo is used as qxl surface, so allocate it as
QXL_GEM_DOMAIN_SURFACE. Should usually be allocated in
PRIV ttm domain then, so this reduces VRAM memory pressure.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
index ce0b9c40fc..1dde3b2ecb 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -758,7 +758,7 @@ static int qxl_plane_prepare_fb(struct drm_plane *plane,
user_bo->shadow = old_bo->shadow;
} else {
qxl_bo_create(qdev, user_bo->gem_base.size,
- true, true, QXL_GEM_DOMAIN_VRAM, NULL,
+ true, true, QXL_GEM_DOMAIN_SURFACE, NULL,
&user_bo->shadow);
}
}
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox