RE: [RFC] hypercall-vsock: add a new vsock transport
On Wednesday, November 10, 2021 6:50 PM, Michael S. Tsirkin wrote: > On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote: > > hypercalls are fundamentally hypervisor dependent though. Yes, each hypervisor needs to support it. We could simplify the design and implementation to the minimal, so that each hypervisor can easily support it. Once every hypervisor has the support, the guest (MigTD) could be a unified version. (e.g. no need for each hypervisor user to develop their own MigTD using their own vsock transport) > Assuming you can carve up a hypervisor independent hypercall, using it for > something as mundane and specific as vsock for TDX seems like a huge overkill. > For example, virtio could benefit from faster vmexits that hypercalls give you > for signalling. > How about a combination of virtio-mmio and hypercalls for fast-path signalling > then? We thought about virtio-mmio. There are some barriers: 1) It wasn't originally intended for x86 machines. The only machine type in QEMU that supports it (to run on x86) is microvm. But "microvm" doesn’t support TDX currently, and adding this support might need larger effort. 2) It's simpler than virtio-pci, but still more complex than hypercall. 3) Some CSPs don't have virtio support in their software, so this might add too much development effort for them. This usage doesn’t need high performance, so faster hypercall for signalling isn't required, I think. (but if hypercall has been verified to be much faster than the current EPT misconfig based notification, it could be added for the general virtio usages) > > > 2) It is simpler. It doesn’t rely on any complex bus enumeration > > > > (e.g. virtio-pci based vsock device may need the whole implementation of > PCI). > > > > Next thing people will try to do is implement a bunch of other device on top > of > it. virtio used pci simply because everyone implements pci. And the reason > for *that* is because implementing a basic pci bus is dead simple, whole of > pci.c in qemu is <3000 LOC. This doesn’t include the PCI enumeration in seaBIOS and the PCI driver in the guest though. Virtio has high performance, I think that's an important reason that more devices are continually added. For this transport, I couldn’t envision that a bunch of devices would be added. It's a simple PV method. > > > > > An example usage is the communication between MigTD and host (Page 8 > > at > > > > https://static.sched.com/hosted_files/kvmforum2021/ef/ > > TDX%20Live%20Migration_Wei%20Wang.pdf). > > > > MigTD communicates to host to assist the migration of the target (user) TD. > > > > MigTD is part of the TCB, so its implementation is expected to be as > > simple as possible > > > > (e.g. bare mental implementation without OS, no PCI driver support). > > > > > > Try to list drawbacks? For example, passthrough for nested virt isn't possible > unlike pci, neither are hardware implementations. > Why hypercall wouldn't be possible for nested virt? L2 hypercall goes to L0 directly and L0 can decide whether to forward the call the L1 (in our case, I think no need as the packet will go out), right? Its drawbacks are obvious (e.g. low performance). In general, I think it could be considered as a complement to virtio. I think most usages would choose virtio as they don’t worry about the complexity and they purse high performance. For some special usages that think virtio is too complex to suffice and they want something simpler, they would consider to use this transport。 Thanks, Wei ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/3] virtio support cache indirect desc
On Wed, 10 Nov 2021 07:53:44 -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 08, 2021 at 10:47:40PM +0800, Xuan Zhuo wrote:
> > On Mon, 8 Nov 2021 08:49:27 -0500, Michael S. Tsirkin
> > wrote:
> > >
> > > Hmm a bunch of comments got ignored. See e.g.
> > > https://lore.kernel.org/r/20211027043851-mutt-send-email-mst%40kernel.org
> > > if they aren't relevant add code comments or commit log text explaining
> > > the
> > > design choice please.
> >
> > I should have responded to related questions, I am guessing whether some
> > emails
> > have been lost.
> >
> > I have sorted out the following 6 questions, if there are any missing
> > questions,
> > please let me know.
> >
> > 1. use list_head
> > In the earliest version, I used pointers directly. You suggest that I use
> > llist_head, but considering that llist_head has atomic operations. There
> > is no
> > competition problem here, so I used list_head.
> >
> > In fact, I did not increase the allocated space for list_head.
> >
> > use as desc array: | vring_desc | vring_desc | vring_desc | vring_desc |
> > use as queue item: | list_head |
>
> the concern is that you touch many cache lines when removing an entry.
>
> I suggest something like:
>
> llist: add a non-atomic list_del_first
>
> One has to know what one's doing, but if one has locked the list
> preventing all accesses, then it's ok to just pop off an entry without
> atomics.
>
Oh, great, but my way of solving the problem is too conservative.
> Signed-off-by: Michael S. Tsirkin
>
> ---
>
> diff --git a/include/linux/llist.h b/include/linux/llist.h
> index 24f207b0190b..13a47dddb12b 100644
> --- a/include/linux/llist.h
> +++ b/include/linux/llist.h
> @@ -247,6 +247,17 @@ static inline struct llist_node *__llist_del_all(struct
> llist_head *head)
>
> extern struct llist_node *llist_del_first(struct llist_head *head);
>
> +static inline struct llist_node *__llist_del_first(struct llist_head *head)
> +{
> + struct llist_node *first = head->first;
> +
> + if (!first)
> + return NULL;
> +
> + head->first = first->next;
> + return first;
> +}
> +
> struct llist_node *llist_reverse_order(struct llist_node *head);
>
> #endif /* LLIST_H */
>
>
> -
>
>
> > 2.
> > > > + if (vq->use_desc_cache && total_sg <=
> > > > VIRT_QUEUE_CACHE_DESC_NUM) {
> > > > + if (vq->desc_cache_chain) {
> > > > + desc = vq->desc_cache_chain;
> > > > + vq->desc_cache_chain = (void *)desc->addr;
> > > > + goto got;
> > > > + }
> > > > + n = VIRT_QUEUE_CACHE_DESC_NUM;
> > >
> > > Hmm. This will allocate more entries than actually used. Why do it?
> >
> >
> > This is because the size of each cache item is fixed, and the logic has been
> > modified in the latest code. I think this problem no longer exists.
> >
> >
> > 3.
> > > What bothers me here is what happens if cache gets
> > > filled on one numa node, then used on another?
> >
> > I'm thinking about another question, how did the cross-numa appear here, and
> > virtio desc queue also has the problem of cross-numa. So is it necessary
> > for us
> > to deal with the cross-numa scene?
>
> It's true that desc queue might be cross numa, and people are looking
> for ways to improve that. Not a reason to make things worse ...
>
I will test for it.
>
> > Indirect desc is used as virtio desc, so as long as it is in the same numa
> > as
> > virito desc. So we can allocate indirect desc cache at the same time when
> > allocating virtio desc queue.
>
> Using it from current node like we do now seems better.
>
> > 4.
> > > So e.g. for rx, we are wasting memory since indirect isn't used.
> >
> > In the current version, desc cache is set up based on pre-queue.
> >
> > So if the desc cache is not used, we don't need to set the desc cache.
> >
> > For example, virtio-net, as long as the tx queue and the rx queue in big
> > packet
> > mode enable desc cache.
>
>
> I liked how in older versions adding indrect enabled it implicitly
> though without need to hack drivers.
I see.
>
> > 5.
> > > Would a better API be a cache size in bytes? This controls how much
> > > memory is spent after all.
> >
> > My design is to set a threshold. When total_sg is greater than this
> > threshold,
> > it will fall back to kmalloc/kfree. When total_sg is less than or equal to
> > this threshold, use the allocated cache.
> >
>
> I know. My question is this, do devices know what a good threshold is?
> If yes how do they know?
I think the driver knows the threshold, for example, MAX_SKB_FRAG + 2 is a
suitable threshold for virtio-net.
>
> > 6. kmem_cache_*
> >
> > I have tested these, the performance is not as good as the method used in
> > this
> > patch.
>
> Do you mean kmem_cache_alloc_bulk/kmem_cache_free_bulk?
> You mentioned just kmem_cache_alloc previously.
I will test for kmem_cache_alloc_bulk.
Re: [PATCH v3 1/3] MAINTAINERS: Update maintainers for paravirt ops and VMware hypervisor interface
On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote: > From: Srivatsa S. Bhat (VMware) > > Deep has decided to transfer maintainership of the VMware hypervisor > interface to Srivatsa, and the joint-maintainership of paravirt ops in > the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file > to reflect this change. > > Signed-off-by: Srivatsa S. Bhat (VMware) > Acked-by: Alexey Makhalov > Acked-by: Deep Shah > Acked-by: Juergen Gross > Cc: sta...@vger.kernel.org Why are MAINTAINERS updates needed for stable? That's not normal :( ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 3/3] MAINTAINERS: Mark VMware mailing list entries as email aliases
From: Srivatsa S. Bhat (VMware) VMware mailing lists in the MAINTAINERS file are private lists meant for VMware-internal review/notification for patches to the respective subsystems. Anyone can post to these addresses, but there is no public read access like open mailing lists, which makes them more like email aliases instead (to reach out to reviewers). So update all the VMware mailing list references in the MAINTAINERS file to mark them as such, using "R: email-al...@vmware.com". Signed-off-by: Srivatsa S. Bhat (VMware) Cc: Zack Rusin Cc: Nadav Amit Cc: Vivek Thampi Cc: Vishal Bhakta Cc: Ronak Doshi Cc: pv-driv...@vmware.com Cc: linux-graphics-maintai...@vmware.com Cc: dri-de...@lists.freedesktop.org Cc: linux-r...@vger.kernel.org Cc: linux-s...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-in...@vger.kernel.org --- MAINTAINERS | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 21c0e49b80b9..073e00ef9434 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6134,8 +6134,8 @@ T:git git://anongit.freedesktop.org/drm/drm-misc F: drivers/gpu/drm/vboxvideo/ DRM DRIVER FOR VMWARE VIRTUAL GPU -M: "VMware Graphics" M: Zack Rusin +R: VMware Graphics Reviewers L: dri-de...@lists.freedesktop.org S: Supported T: git git://anongit.freedesktop.org/drm/drm-misc @@ -14189,7 +14189,7 @@ F: include/uapi/linux/ppdev.h PARAVIRT_OPS INTERFACE M: Juergen Gross M: Srivatsa S. Bhat (VMware) -M: "VMware, Inc." +R: VMware PV-Drivers Reviewers L: virtualization@lists.linux-foundation.org L: x...@kernel.org S: Supported @@ -20032,7 +20032,7 @@ F: tools/testing/vsock/ VMWARE BALLOON DRIVER M: Nadav Amit -M: "VMware, Inc." +R: VMware PV-Drivers Reviewers L: linux-ker...@vger.kernel.org S: Maintained F: drivers/misc/vmw_balloon.c @@ -20040,7 +20040,7 @@ F: drivers/misc/vmw_balloon.c VMWARE HYPERVISOR INTERFACE M: Srivatsa S. Bhat (VMware) M: Alexey Makhalov -M: "VMware, Inc." +R: VMware PV-Drivers Reviewers L: virtualization@lists.linux-foundation.org L: x...@kernel.org S: Supported @@ -20050,14 +20050,14 @@ F:arch/x86/kernel/cpu/vmware.c VMWARE PVRDMA DRIVER M: Adit Ranadive -M: VMware PV-Drivers +R: VMware PV-Drivers Reviewers L: linux-r...@vger.kernel.org S: Maintained F: drivers/infiniband/hw/vmw_pvrdma/ VMware PVSCSI driver M: Vishal Bhakta -M: VMware PV-Drivers +R: VMware PV-Drivers Reviewers L: linux-s...@vger.kernel.org S: Maintained F: drivers/scsi/vmw_pvscsi.c @@ -20065,7 +20065,7 @@ F: drivers/scsi/vmw_pvscsi.h VMWARE VIRTUAL PTP CLOCK DRIVER M: Vivek Thampi -M: "VMware, Inc." +R: VMware PV-Drivers Reviewers L: net...@vger.kernel.org S: Supported F: drivers/ptp/ptp_vmw.c @@ -20073,15 +20073,15 @@ F:drivers/ptp/ptp_vmw.c VMWARE VMCI DRIVER M: Jorgen Hansen M: Vishnu Dasa +R: VMware PV-Drivers Reviewers L: linux-ker...@vger.kernel.org -L: pv-driv...@vmware.com (private) S: Maintained F: drivers/misc/vmw_vmci/ VMWARE VMMOUSE SUBDRIVER M: Zack Rusin -M: "VMware Graphics" -M: "VMware, Inc." +R: VMware Graphics Reviewers +R: VMware PV-Drivers Reviewers L: linux-in...@vger.kernel.org S: Maintained F: drivers/input/mouse/vmmouse.c @@ -20089,7 +20089,7 @@ F: drivers/input/mouse/vmmouse.h VMWARE VMXNET3 ETHERNET DRIVER M: Ronak Doshi -M: pv-driv...@vmware.com +R: VMware PV-Drivers Reviewers L: net...@vger.kernel.org S: Maintained F: drivers/net/vmxnet3/ ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 2/3] MAINTAINERS: Add Zack as maintainer of vmmouse driver
From: Srivatsa S. Bhat (VMware) Zack Rusin will be taking over the maintainership of the VMware vmmouse driver. Update the MAINTAINERS file to reflect this change. Signed-off-by: Srivatsa S. Bhat (VMware) Acked-by: Zack Rusin Cc: linux-graphics-maintai...@vmware.com Cc: pv-driv...@vmware.com Cc: linux-in...@vger.kernel.org Cc: sta...@vger.kernel.org --- MAINTAINERS |1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0329d67c5bcf..21c0e49b80b9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -20079,6 +20079,7 @@ S: Maintained F: drivers/misc/vmw_vmci/ VMWARE VMMOUSE SUBDRIVER +M: Zack Rusin M: "VMware Graphics" M: "VMware, Inc." L: linux-in...@vger.kernel.org ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 1/3] MAINTAINERS: Update maintainers for paravirt ops and VMware hypervisor interface
From: Srivatsa S. Bhat (VMware) Deep has decided to transfer maintainership of the VMware hypervisor interface to Srivatsa, and the joint-maintainership of paravirt ops in the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file to reflect this change. Signed-off-by: Srivatsa S. Bhat (VMware) Acked-by: Alexey Makhalov Acked-by: Deep Shah Acked-by: Juergen Gross Cc: sta...@vger.kernel.org --- MAINTAINERS |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0ad926ba362f..0329d67c5bcf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14188,7 +14188,7 @@ F: include/uapi/linux/ppdev.h PARAVIRT_OPS INTERFACE M: Juergen Gross -M: Deep Shah +M: Srivatsa S. Bhat (VMware) M: "VMware, Inc." L: virtualization@lists.linux-foundation.org L: x...@kernel.org @@ -20038,10 +20038,13 @@ S:Maintained F: drivers/misc/vmw_balloon.c VMWARE HYPERVISOR INTERFACE -M: Deep Shah +M: Srivatsa S. Bhat (VMware) +M: Alexey Makhalov M: "VMware, Inc." L: virtualization@lists.linux-foundation.org +L: x...@kernel.org S: Supported +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vmware F: arch/x86/include/asm/vmware.h F: arch/x86/kernel/cpu/vmware.c ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 0/3] Update VMware maintainer entries
This series updates a few maintainer entries for VMware-maintained subsystems and cleans up references to VMware's private mailing lists to make it clear that they are effectively email-aliases to reach out to reviewers. Changes from v1->v3: - Add Zack as the named maintainer for vmmouse driver - Use R: to denote email-aliases for VMware reviewers Regards, Srivatsa --- Srivatsa S. Bhat (VMware) (3): MAINTAINERS: Update maintainers for paravirt ops and VMware hypervisor interface MAINTAINERS: Add Zack as maintainer of vmmouse driver MAINTAINERS: Mark VMware mailing list entries as email aliases MAINTAINERS | 30 +- 1 file changed, 17 insertions(+), 13 deletions(-) ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/2] MAINTAINERS: Mark VMware mailing list entries as private
On Wed, Nov 10, 2021 at 05:40:09PM +, Nadav Amit wrote: > > > > On Nov 10, 2021, at 9:20 AM, Srivatsa S. Bhat > > wrote: > > > > On Tue, Nov 09, 2021 at 01:57:31PM -0800, Joe Perches wrote: > >> On Tue, 2021-11-09 at 00:58 +, Nadav Amit wrote: > On Nov 8, 2021, at 4:37 PM, Joe Perches wrote: > On Mon, 2021-11-08 at 16:22 -0800, Srivatsa S. Bhat wrote: > > So it's an exploder not an actual maintainer and it likely isn't > publically archived with any normal list mechanism. > > So IMO "private" isn't appropriate. Neither is "L:" > Perhaps just mark it as what it is as an "exploder". > > Or maybe these blocks should be similar to: > > M: Name of Lead Developer > M: VMware maintainers -maintain...@vmlinux.com> > >> > >> Maybe adding entries like > >> > >> M: Named maintainer > >> R: VMware reviewers -maintain...@vmware.com> > >> > >> would be best/simplest. > >> > > > > Sure, that sounds good to me. I also considered adding "(email alias)" > > like Juergen suggested, but I think the R: entry is clear enough. > > Please find the updated patch below. > > > > --- > > > > From f66faa238facf504cfc66325912ce7af8cbf79ec Mon Sep 17 00:00:00 2001 > > From: "Srivatsa S. Bhat (VMware)" > > Date: Mon, 8 Nov 2021 11:46:57 -0800 > > Subject: [PATCH v2 2/2] MAINTAINERS: Mark VMware mailing list entries as > > email > > aliases > > > > VMware mailing lists in the MAINTAINERS file are private lists meant > > for VMware-internal review/notification for patches to the respective > > subsystems. Anyone can post to these addresses, but there is no public > > read access like open mailing lists, which makes them more like email > > aliases instead (to reach out to reviewers). > > > > So update all the VMware mailing list references in the MAINTAINERS > > file to mark them as such, using "R: email-al...@vmware.com". > > > > Signed-off-by: Srivatsa S. Bhat (VMware) > > Cc: Zack Rusin > > Cc: Nadav Amit > > Cc: Vivek Thampi > > Cc: Vishal Bhakta > > Cc: Ronak Doshi > > Cc: pv-driv...@vmware.com > > Cc: linux-graphics-maintai...@vmware.com > > Cc: dri-de...@lists.freedesktop.org > > Cc: linux-r...@vger.kernel.org > > Cc: linux-s...@vger.kernel.org > > Cc: net...@vger.kernel.org > > Cc: linux-in...@vger.kernel.org > > --- > > MAINTAINERS | 22 +++--- > > 1 file changed, 11 insertions(+), 11 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 118cf8170d02..4372d79027e9 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -6134,8 +6134,8 @@ T:git git://anongit.freedesktop.org/drm/drm-misc > > F: drivers/gpu/drm/vboxvideo/ > > > > DRM DRIVER FOR VMWARE VIRTUAL GPU > > -M: "VMware Graphics" > > M: Zack Rusin > > +R: VMware Graphics Reviewers > > L: dri-de...@lists.freedesktop.org > > S: Supported > > T: git git://anongit.freedesktop.org/drm/drm-misc > > @@ -14189,7 +14189,7 @@ F: include/uapi/linux/ppdev.h > > PARAVIRT_OPS INTERFACE > > M: Juergen Gross > > M: Srivatsa S. Bhat (VMware) > > -L: pv-driv...@vmware.com (private) > > +R: VMware PV-Drivers Reviewers > > This patch that you just sent seems to go on top of the previous patches > (as it removes "L: pv-driv...@vmware.com (private)”). > Actually, that's a bit misleading, since I had corrected that entry in the first patch itself, while adding myself as the maintainer. So there are still only 2 patches in this series right now. Thanks for pointing this out! I'll move the VMware list modifications out of the first patch, to avoid confusion. > Since the patches were still not merged, I would presume you should squash > the old 2/2 with this new patch and send v3 of these patches. > I'll send out a v3, and also add Zack Rusin as the maintainer for the vmmouse sub-driver, since it does not have a named maintainer at the moment (Zack indicated that he will be taking up the maintainership). Thank you! Regards, Srivatsa ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/2] MAINTAINERS: Mark VMware mailing list entries as private
> On Nov 10, 2021, at 9:20 AM, Srivatsa S. Bhat wrote: > > On Tue, Nov 09, 2021 at 01:57:31PM -0800, Joe Perches wrote: >> On Tue, 2021-11-09 at 00:58 +, Nadav Amit wrote: On Nov 8, 2021, at 4:37 PM, Joe Perches wrote: On Mon, 2021-11-08 at 16:22 -0800, Srivatsa S. Bhat wrote: So it's an exploder not an actual maintainer and it likely isn't publically archived with any normal list mechanism. So IMO "private" isn't appropriate. Neither is "L:" Perhaps just mark it as what it is as an "exploder". Or maybe these blocks should be similar to: M: Name of Lead Developer M: VMware maintainers -maintain...@vmlinux.com> >> >> Maybe adding entries like >> >> M: Named maintainer >> R: VMware reviewers -maintain...@vmware.com> >> >> would be best/simplest. >> > > Sure, that sounds good to me. I also considered adding "(email alias)" > like Juergen suggested, but I think the R: entry is clear enough. > Please find the updated patch below. > > --- > > From f66faa238facf504cfc66325912ce7af8cbf79ec Mon Sep 17 00:00:00 2001 > From: "Srivatsa S. Bhat (VMware)" > Date: Mon, 8 Nov 2021 11:46:57 -0800 > Subject: [PATCH v2 2/2] MAINTAINERS: Mark VMware mailing list entries as email > aliases > > VMware mailing lists in the MAINTAINERS file are private lists meant > for VMware-internal review/notification for patches to the respective > subsystems. Anyone can post to these addresses, but there is no public > read access like open mailing lists, which makes them more like email > aliases instead (to reach out to reviewers). > > So update all the VMware mailing list references in the MAINTAINERS > file to mark them as such, using "R: email-al...@vmware.com". > > Signed-off-by: Srivatsa S. Bhat (VMware) > Cc: Zack Rusin > Cc: Nadav Amit > Cc: Vivek Thampi > Cc: Vishal Bhakta > Cc: Ronak Doshi > Cc: pv-driv...@vmware.com > Cc: linux-graphics-maintai...@vmware.com > Cc: dri-de...@lists.freedesktop.org > Cc: linux-r...@vger.kernel.org > Cc: linux-s...@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: linux-in...@vger.kernel.org > --- > MAINTAINERS | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 118cf8170d02..4372d79027e9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6134,8 +6134,8 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > F:drivers/gpu/drm/vboxvideo/ > > DRM DRIVER FOR VMWARE VIRTUAL GPU > -M: "VMware Graphics" > M:Zack Rusin > +R: VMware Graphics Reviewers > L:dri-de...@lists.freedesktop.org > S:Supported > T:git git://anongit.freedesktop.org/drm/drm-misc > @@ -14189,7 +14189,7 @@ F:include/uapi/linux/ppdev.h > PARAVIRT_OPS INTERFACE > M:Juergen Gross > M:Srivatsa S. Bhat (VMware) > -L: pv-driv...@vmware.com (private) > +R: VMware PV-Drivers Reviewers This patch that you just sent seems to go on top of the previous patches (as it removes "L: pv-driv...@vmware.com (private)”). Since the patches were still not merged, I would presume you should squash the old 2/2 with this new patch and send v3 of these patches. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/2] MAINTAINERS: Mark VMware mailing list entries as private
On Tue, Nov 09, 2021 at 01:57:31PM -0800, Joe Perches wrote: > On Tue, 2021-11-09 at 00:58 +, Nadav Amit wrote: > > > On Nov 8, 2021, at 4:37 PM, Joe Perches wrote: > > > On Mon, 2021-11-08 at 16:22 -0800, Srivatsa S. Bhat wrote: > > > > > > So it's an exploder not an actual maintainer and it likely isn't > > > publically archived with any normal list mechanism. > > > > > > So IMO "private" isn't appropriate. Neither is "L:" > > > Perhaps just mark it as what it is as an "exploder". > > > > > > Or maybe these blocks should be similar to: > > > > > > M:Name of Lead Developer > > > M:VMware maintainers -maintain...@vmlinux.com> > > Maybe adding entries like > > M:Named maintainer > R:VMware reviewers -maintain...@vmware.com> > > would be best/simplest. > Sure, that sounds good to me. I also considered adding "(email alias)" like Juergen suggested, but I think the R: entry is clear enough. Please find the updated patch below. --- >From f66faa238facf504cfc66325912ce7af8cbf79ec Mon Sep 17 00:00:00 2001 From: "Srivatsa S. Bhat (VMware)" Date: Mon, 8 Nov 2021 11:46:57 -0800 Subject: [PATCH v2 2/2] MAINTAINERS: Mark VMware mailing list entries as email aliases VMware mailing lists in the MAINTAINERS file are private lists meant for VMware-internal review/notification for patches to the respective subsystems. Anyone can post to these addresses, but there is no public read access like open mailing lists, which makes them more like email aliases instead (to reach out to reviewers). So update all the VMware mailing list references in the MAINTAINERS file to mark them as such, using "R: email-al...@vmware.com". Signed-off-by: Srivatsa S. Bhat (VMware) Cc: Zack Rusin Cc: Nadav Amit Cc: Vivek Thampi Cc: Vishal Bhakta Cc: Ronak Doshi Cc: pv-driv...@vmware.com Cc: linux-graphics-maintai...@vmware.com Cc: dri-de...@lists.freedesktop.org Cc: linux-r...@vger.kernel.org Cc: linux-s...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-in...@vger.kernel.org --- MAINTAINERS | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 118cf8170d02..4372d79027e9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6134,8 +6134,8 @@ T:git git://anongit.freedesktop.org/drm/drm-misc F: drivers/gpu/drm/vboxvideo/ DRM DRIVER FOR VMWARE VIRTUAL GPU -M: "VMware Graphics" M: Zack Rusin +R: VMware Graphics Reviewers L: dri-de...@lists.freedesktop.org S: Supported T: git git://anongit.freedesktop.org/drm/drm-misc @@ -14189,7 +14189,7 @@ F: include/uapi/linux/ppdev.h PARAVIRT_OPS INTERFACE M: Juergen Gross M: Srivatsa S. Bhat (VMware) -L: pv-driv...@vmware.com (private) +R: VMware PV-Drivers Reviewers L: virtualization@lists.linux-foundation.org L: x...@kernel.org S: Supported @@ -20032,7 +20032,7 @@ F: tools/testing/vsock/ VMWARE BALLOON DRIVER M: Nadav Amit -M: "VMware, Inc." +R: VMware PV-Drivers Reviewers L: linux-ker...@vger.kernel.org S: Maintained F: drivers/misc/vmw_balloon.c @@ -20040,7 +20040,7 @@ F: drivers/misc/vmw_balloon.c VMWARE HYPERVISOR INTERFACE M: Srivatsa S. Bhat (VMware) M: Alexey Makhalov -L: pv-driv...@vmware.com (private) +R: VMware PV-Drivers Reviewers L: virtualization@lists.linux-foundation.org L: x...@kernel.org S: Supported @@ -20050,14 +20050,14 @@ F:arch/x86/kernel/cpu/vmware.c VMWARE PVRDMA DRIVER M: Adit Ranadive -M: VMware PV-Drivers +R: VMware PV-Drivers Reviewers L: linux-r...@vger.kernel.org S: Maintained F: drivers/infiniband/hw/vmw_pvrdma/ VMware PVSCSI driver M: Vishal Bhakta -M: VMware PV-Drivers +R: VMware PV-Drivers Reviewers L: linux-s...@vger.kernel.org S: Maintained F: drivers/scsi/vmw_pvscsi.c @@ -20065,7 +20065,7 @@ F: drivers/scsi/vmw_pvscsi.h VMWARE VIRTUAL PTP CLOCK DRIVER M: Vivek Thampi -M: "VMware, Inc." +R: VMware PV-Drivers Reviewers L: net...@vger.kernel.org S: Supported F: drivers/ptp/ptp_vmw.c @@ -20073,14 +20073,14 @@ F:drivers/ptp/ptp_vmw.c VMWARE VMCI DRIVER M: Jorgen Hansen M: Vishnu Dasa +R: VMware PV-Drivers Reviewers L: linux-ker...@vger.kernel.org -L: pv-driv...@vmware.com (private) S: Maintained F: drivers/misc/vmw_vmci/ VMWARE VMMOUSE SUBDRIVER -M: "VMware Graphics" -M: "VMware, Inc." +R: VMware Graphics Reviewers +R: VMware PV-Drivers Reviewers L: linux-in...@vger.kernel.org S: Maintained F: drivers/input/mouse/vmmouse.c @@ -20088,7 +20088,7 @@ F: drivers/input/mouse/vmmouse.h VMWARE VMXNET3 ETHERNET DRIVER M: Ronak Doshi -M: pv-driv...@vmware.com +R: VMware PV-Drivers Reviewers L: net...@vger.kernel.org S: Maintained F: drivers/net/vmxnet3/ -- 2.25.1 _
[GIT PULL] virtio-mem changes for v5.16
Hi Linus,
usually this would have went via the vhost tree, but as this patch depends
on some patches that just went in via Andrews tree and MST doesn't have
any other patches for this merge window, I'm sending it myself
and base it on current mainline that contains the relevant commits
already. Thanks!
The following changes since commit cb690f5238d71f543f4ce874aa59237cf53a877c:
Merge tag 'for-5.16/drivers-2021-11-09' of git://git.kernel.dk/linux-block
(2021-11-09 11:24:08 -0800)
are available in the Git repository at:
https://github.com/davidhildenbrand/linux.git tags/virtio-mem-for-5.16
for you to fetch changes up to 61082ad6a6e1f999eef7e7e90046486c87933b1e:
virtio-mem: support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE (2021-11-10 15:32:38
+0100)
virtio-mem: support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE
Support the VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE feature in virtio-mem, now
that "accidential" access to logically unplugged memory inside added
Linux memory blocks is no longer possible, because we:
1. Removed /dev/kmem in commit bbcd53c96071 ("drivers/char: remove
/dev/kmem for good")
2. Disallowed access to virtio-mem device memory via /dev/mem in commit
2128f4e21aa ("virtio-mem: disallow mapping virtio-mem memory via
/dev/mem")
3. Sanitized access to virtio-mem device memory via /proc/kcore in
commit 0daa322b8ff9 ("fs/proc/kcore: don't read offline sections,
logically offline pages and hwpoisoned pages")
4. Sanitized access to virtio-mem device memory via /proc/vmcore in
commit ce2814622e84 ("virtio-mem: kdump mode to sanitize /proc/vmcore
access")
The new VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE feature that will be required
by some hypervisors implementing virtio-mem in the near future, so let's
support it now that we safely can.
Signed-off-by: David Hildenbrand
David Hildenbrand (1):
virtio-mem: support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE
drivers/virtio/virtio_mem.c | 1 +
include/uapi/linux/virtio_mem.h | 9 ++---
2 files changed, 7 insertions(+), 3 deletions(-)
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 07/12] x86/sev: Setup code to park APs in the AP Jump Table
On Mon, Sep 13, 2021 at 05:55:58PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The AP Jump Table under SEV-ES contains the reset vector where non-boot
> CPUs start executing when coming out of reset. This means that a CPU
> coming out of the AP-reset-hold VMGEXIT also needs to start executing at
> the reset vector stored in the AP Jump Table.
>
> The problem is to find a safe place to put the real-mode code which
> executes the VMGEXIT and jumps to the reset vector. The code can not be
> in kernel memory, because after kexec that memory is owned by the new
> kernel and the code might have been overwritten.
>
> Fortunately the AP Jump Table itself is a safe place, because the
> memory is not owned by the OS and will not be overwritten by a new
> kernel started through kexec. The table is 4k in size and only the
> first 4 bytes are used for the reset vector. This leaves enough space
> for some 16-bit code to do the job and even a small stack.
"The AP jump table must be 4K in size, in encrypted memory and it must
be 4K (page) aligned. There can only be one AP jump table and it should
reside in memory that has been marked as reserved by UEFI."
I think we need to state in the spec that some of that space can be used
by the OS so that future changes to the spec do not cause trouble.
> Install 16-bit code into the AP Jump Table under SEV-ES after the APs
> have been brought up. The code will do an AP-reset-hold VMGEXIT and jump
> to the reset vector after being woken up.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/include/asm/realmode.h | 2 +
> arch/x86/include/asm/sev-ap-jumptable.h | 25 +
> arch/x86/kernel/sev.c | 105 +++
> arch/x86/realmode/Makefile | 9 +-
> arch/x86/realmode/rmpiggy.S | 6 ++
> arch/x86/realmode/sev/Makefile | 41
> arch/x86/realmode/sev/ap_jump_table.S | 130
> arch/x86/realmode/sev/ap_jump_table.lds | 24 +
> 8 files changed, 341 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/include/asm/sev-ap-jumptable.h
> create mode 100644 arch/x86/realmode/sev/Makefile
> create mode 100644 arch/x86/realmode/sev/ap_jump_table.S
> create mode 100644 arch/x86/realmode/sev/ap_jump_table.lds
>
> diff --git a/arch/x86/include/asm/realmode.h b/arch/x86/include/asm/realmode.h
> index 5db5d083c873..29590a4ddf24 100644
> --- a/arch/x86/include/asm/realmode.h
> +++ b/arch/x86/include/asm/realmode.h
> @@ -62,6 +62,8 @@ extern unsigned long initial_gs;
> extern unsigned long initial_stack;
> #ifdef CONFIG_AMD_MEM_ENCRYPT
> extern unsigned long initial_vc_handler;
> +extern unsigned char rm_ap_jump_table_blob[];
> +extern unsigned char rm_ap_jump_table_blob_end[];
> #endif
>
> extern unsigned char real_mode_blob[];
> diff --git a/arch/x86/include/asm/sev-ap-jumptable.h
> b/arch/x86/include/asm/sev-ap-jumptable.h
> new file mode 100644
> index ..1c8b2ce779e2
> --- /dev/null
> +++ b/arch/x86/include/asm/sev-ap-jumptable.h
Why a separate header? arch/x86/include/asm/sev.h looks small enough.
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * AMD Encrypted Register State Support
> + *
> + * Author: Joerg Roedel
> + */
> +#ifndef __ASM_SEV_AP_JUMPTABLE_H
> +#define __ASM_SEV_AP_JUMPTABLE_H
> +
> +#define SEV_APJT_CS16 0x8
> +#define SEV_APJT_DS16 0x10
> +
> +#define SEV_APJT_ENTRY 0x10
> +
> +#ifndef __ASSEMBLY__
> +
> +struct sev_ap_jump_table_header {
> + u16 reset_ip;
> + u16 reset_cs;
> + u16 gdt_offset;
I guess you should state that the first two members are as the spec
mandates and cannot be moved around or changed or so.
Also, this gdt_offset thing looks like it wants to be ap_jumptable_gdt,
no?
> +};
> +
> +#endif /* !__ASSEMBLY__ */
> +
> +#endif /* __ASM_SEV_AP_JUMPTABLE_H */
> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
> index eedba56b6bac..a98eab926682 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -19,6 +19,7 @@
> #include
> #include
>
> +#include
> #include
> #include
> #include
> @@ -45,6 +46,9 @@ static struct ghcb __initdata *boot_ghcb;
> /* Cached AP Jump Table Address */
> static phys_addr_t sev_es_jump_table_pa;
>
> +/* Whether the AP Jump Table blob was successfully installed */
> +static bool sev_ap_jumptable_blob_installed __ro_after_init;
> +
> /* #VC handler runtime per-CPU data */
> struct sev_es_runtime_data {
> struct ghcb ghcb_page;
> @@ -749,6 +753,107 @@ static void __init sev_es_setup_play_dead(void)
> static inline void sev_es_setup_play_dead(void) { }
> #endif
>
> +/*
> + * This function make the necessary runtime changes to the AP Jump Table
> blob.
s/This function make/Make/
Ditto for the other "This function" below.
> + * For now this only sets up the GDT used while the code executes. The GDT
> needs
> + * to contain 16-bit code and data segments with
Re: [PATCH v4 0/3] virtio support cache indirect desc
On Wed, Nov 10, 2021 at 07:53:49AM -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 08, 2021 at 10:47:40PM +0800, Xuan Zhuo wrote:
> > On Mon, 8 Nov 2021 08:49:27 -0500, Michael S. Tsirkin
> > wrote:
> > >
> > > Hmm a bunch of comments got ignored. See e.g.
> > > https://lore.kernel.org/r/20211027043851-mutt-send-email-mst%40kernel.org
> > > if they aren't relevant add code comments or commit log text explaining
> > > the
> > > design choice please.
> >
> > I should have responded to related questions, I am guessing whether some
> > emails
> > have been lost.
> >
> > I have sorted out the following 6 questions, if there are any missing
> > questions,
> > please let me know.
> >
> > 1. use list_head
> > In the earliest version, I used pointers directly. You suggest that I use
> > llist_head, but considering that llist_head has atomic operations. There
> > is no
> > competition problem here, so I used list_head.
> >
> > In fact, I did not increase the allocated space for list_head.
> >
> > use as desc array: | vring_desc | vring_desc | vring_desc | vring_desc |
> > use as queue item: | list_head |
>
> the concern is that you touch many cache lines when removing an entry.
>
> I suggest something like:
>
> llist: add a non-atomic list_del_first
>
> One has to know what one's doing, but if one has locked the list
> preventing all accesses, then it's ok to just pop off an entry without
> atomics.
>
> Signed-off-by: Michael S. Tsirkin
>
> ---
>
> diff --git a/include/linux/llist.h b/include/linux/llist.h
> index 24f207b0190b..13a47dddb12b 100644
> --- a/include/linux/llist.h
> +++ b/include/linux/llist.h
> @@ -247,6 +247,17 @@ static inline struct llist_node *__llist_del_all(struct
> llist_head *head)
>
> extern struct llist_node *llist_del_first(struct llist_head *head);
>
> +static inline struct llist_node *__llist_del_first(struct llist_head *head)
> +{
> + struct llist_node *first = head->first;
> +
> + if (!first)
> + return NULL;
> +
> + head->first = first->next;
> + return first;
> +}
> +
> struct llist_node *llist_reverse_order(struct llist_node *head);
>
> #endif /* LLIST_H */
>
>
> -
>
>
> > 2.
> > > > + if (vq->use_desc_cache && total_sg <=
> > > > VIRT_QUEUE_CACHE_DESC_NUM) {
> > > > + if (vq->desc_cache_chain) {
> > > > + desc = vq->desc_cache_chain;
> > > > + vq->desc_cache_chain = (void *)desc->addr;
> > > > + goto got;
> > > > + }
> > > > + n = VIRT_QUEUE_CACHE_DESC_NUM;
> > >
> > > Hmm. This will allocate more entries than actually used. Why do it?
> >
> >
> > This is because the size of each cache item is fixed, and the logic has been
> > modified in the latest code. I think this problem no longer exists.
> >
> >
> > 3.
> > > What bothers me here is what happens if cache gets
> > > filled on one numa node, then used on another?
> >
> > I'm thinking about another question, how did the cross-numa appear here, and
> > virtio desc queue also has the problem of cross-numa. So is it necessary
> > for us
> > to deal with the cross-numa scene?
>
> It's true that desc queue might be cross numa, and people are looking
> for ways to improve that. Not a reason to make things worse ...
>
To add to that, given it's a concern, how about actually
testing performance for this config?
> > Indirect desc is used as virtio desc, so as long as it is in the same numa
> > as
> > virito desc. So we can allocate indirect desc cache at the same time when
> > allocating virtio desc queue.
>
> Using it from current node like we do now seems better.
>
> > 4.
> > > So e.g. for rx, we are wasting memory since indirect isn't used.
> >
> > In the current version, desc cache is set up based on pre-queue.
> >
> > So if the desc cache is not used, we don't need to set the desc cache.
> >
> > For example, virtio-net, as long as the tx queue and the rx queue in big
> > packet
> > mode enable desc cache.
>
>
> I liked how in older versions adding indrect enabled it implicitly
> though without need to hack drivers.
>
> > 5.
> > > Would a better API be a cache size in bytes? This controls how much
> > > memory is spent after all.
> >
> > My design is to set a threshold. When total_sg is greater than this
> > threshold,
> > it will fall back to kmalloc/kfree. When total_sg is less than or equal to
> > this threshold, use the allocated cache.
> >
>
> I know. My question is this, do devices know what a good threshold is?
> If yes how do they know?
>
> > 6. kmem_cache_*
> >
> > I have tested these, the performance is not as good as the method used in
> > this
> > patch.
>
> Do you mean kmem_cache_alloc_bulk/kmem_cache_free_bulk?
> You mentioned just kmem_cache_alloc previously.
>
> >
> > Thanks.
___
Virtualization mailing list
Virtualizatio
Re: [PATCH v4 0/3] virtio support cache indirect desc
On Mon, Nov 08, 2021 at 10:47:40PM +0800, Xuan Zhuo wrote:
> On Mon, 8 Nov 2021 08:49:27 -0500, Michael S. Tsirkin wrote:
> >
> > Hmm a bunch of comments got ignored. See e.g.
> > https://lore.kernel.org/r/20211027043851-mutt-send-email-mst%40kernel.org
> > if they aren't relevant add code comments or commit log text explaining the
> > design choice please.
>
> I should have responded to related questions, I am guessing whether some
> emails
> have been lost.
>
> I have sorted out the following 6 questions, if there are any missing
> questions,
> please let me know.
>
> 1. use list_head
> In the earliest version, I used pointers directly. You suggest that I use
> llist_head, but considering that llist_head has atomic operations. There is
> no
> competition problem here, so I used list_head.
>
> In fact, I did not increase the allocated space for list_head.
>
> use as desc array: | vring_desc | vring_desc | vring_desc | vring_desc |
> use as queue item: | list_head |
the concern is that you touch many cache lines when removing an entry.
I suggest something like:
llist: add a non-atomic list_del_first
One has to know what one's doing, but if one has locked the list
preventing all accesses, then it's ok to just pop off an entry without
atomics.
Signed-off-by: Michael S. Tsirkin
---
diff --git a/include/linux/llist.h b/include/linux/llist.h
index 24f207b0190b..13a47dddb12b 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -247,6 +247,17 @@ static inline struct llist_node *__llist_del_all(struct
llist_head *head)
extern struct llist_node *llist_del_first(struct llist_head *head);
+static inline struct llist_node *__llist_del_first(struct llist_head *head)
+{
+ struct llist_node *first = head->first;
+
+ if (!first)
+ return NULL;
+
+ head->first = first->next;
+ return first;
+}
+
struct llist_node *llist_reverse_order(struct llist_node *head);
#endif /* LLIST_H */
-
> 2.
> > > + if (vq->use_desc_cache && total_sg <= VIRT_QUEUE_CACHE_DESC_NUM) {
> > > + if (vq->desc_cache_chain) {
> > > + desc = vq->desc_cache_chain;
> > > + vq->desc_cache_chain = (void *)desc->addr;
> > > + goto got;
> > > + }
> > > + n = VIRT_QUEUE_CACHE_DESC_NUM;
> >
> > Hmm. This will allocate more entries than actually used. Why do it?
>
>
> This is because the size of each cache item is fixed, and the logic has been
> modified in the latest code. I think this problem no longer exists.
>
>
> 3.
> > What bothers me here is what happens if cache gets
> > filled on one numa node, then used on another?
>
> I'm thinking about another question, how did the cross-numa appear here, and
> virtio desc queue also has the problem of cross-numa. So is it necessary for
> us
> to deal with the cross-numa scene?
It's true that desc queue might be cross numa, and people are looking
for ways to improve that. Not a reason to make things worse ...
> Indirect desc is used as virtio desc, so as long as it is in the same numa as
> virito desc. So we can allocate indirect desc cache at the same time when
> allocating virtio desc queue.
Using it from current node like we do now seems better.
> 4.
> > So e.g. for rx, we are wasting memory since indirect isn't used.
>
> In the current version, desc cache is set up based on pre-queue.
>
> So if the desc cache is not used, we don't need to set the desc cache.
>
> For example, virtio-net, as long as the tx queue and the rx queue in big
> packet
> mode enable desc cache.
I liked how in older versions adding indrect enabled it implicitly
though without need to hack drivers.
> 5.
> > Would a better API be a cache size in bytes? This controls how much
> > memory is spent after all.
>
> My design is to set a threshold. When total_sg is greater than this threshold,
> it will fall back to kmalloc/kfree. When total_sg is less than or equal to
> this threshold, use the allocated cache.
>
I know. My question is this, do devices know what a good threshold is?
If yes how do they know?
> 6. kmem_cache_*
>
> I have tested these, the performance is not as good as the method used in this
> patch.
Do you mean kmem_cache_alloc_bulk/kmem_cache_free_bulk?
You mentioned just kmem_cache_alloc previously.
>
> Thanks.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 7/9] drm/simpledrm: Enable FB_DAMAGE_CLIPS property
Hi Am 10.11.21 um 13:34 schrieb Noralf Trønnes: Den 10.11.2021 11.37, skrev Thomas Zimmermann: Enable the FB_DAMAGE_CLIPS property to reduce display-update overhead. Also fixes a warning in the kernel log. simple-framebuffer simple-framebuffer.0: [drm] drm_plane_enable_fb_damage_clips() not called Fix the computation of the blit rectangle. This wasn't an issue so far, as simpledrm always blitted the full framebuffer. The code now supports damage clipping and virtual screen sizes. v3: * fix drm_dev_enter() error path (Noralf) * remove unnecessary clipping from update function (Noralf) Signed-off-by: Thomas Zimmermann --- Reviewed-by: Noralf Trønnes Thank you so much for reviewing. Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 7/9] drm/simpledrm: Enable FB_DAMAGE_CLIPS property
Den 10.11.2021 11.37, skrev Thomas Zimmermann: > Enable the FB_DAMAGE_CLIPS property to reduce display-update > overhead. Also fixes a warning in the kernel log. > > simple-framebuffer simple-framebuffer.0: [drm] > drm_plane_enable_fb_damage_clips() not called > > Fix the computation of the blit rectangle. This wasn't an issue so > far, as simpledrm always blitted the full framebuffer. The code now > supports damage clipping and virtual screen sizes. > > v3: > * fix drm_dev_enter() error path (Noralf) > * remove unnecessary clipping from update function (Noralf) > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Noralf Trønnes ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC] hypercall-vsock: add a new vsock transport
On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote: Hi, We plan to add a new vsock transport based on hypercall (e.g. vmcall on Intel CPUs). It transports AF_VSOCK packets between the guest and host, which is similar to virtio-vsock, vmci-vsock and hyperv-vsock. Compared to the above listed vsock transports which are designed for high performance, the main advantages of hypercall-vsock are: 1) It is VMM agnostic. For example, one guest working on hypercall-vsock can run on either KVM, Hyperv, or VMware. 2) It is simpler. It doesn't rely on any complex bus enumeration (e.g. virtio-pci based vsock device may need the whole implementation of PCI). An example usage is the communication between MigTD and host (Page 8 at https://static.sched.com/hosted_files/kvmforum2021/ef/TDX%20Live%20Migration_Wei%20Wang.pdf). MigTD communicates to host to assist the migration of the target (user) TD. MigTD is part of the TCB, so its implementation is expected to be as simple as possible (e.g. bare mental implementation without OS, no PCI driver support). Adding Andra and Sergio, because IIRC Firecracker and libkrun emulates virtio-vsock with virtio-mmio so the implementation should be simple and also not directly tied to a specific VMM. Maybe this fit for your use case too, in this way we don't have to maintain another driver. Thanks, Stefano ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC] hypercall-vsock: add a new vsock transport
On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote: > Hi, > > > > We plan to add a new vsock transport based on hypercall (e.g. vmcall on Intel > CPUs). > > It transports AF_VSOCK packets between the guest and host, which is similar to > > virtio-vsock, vmci-vsock and hyperv-vsock. > > > > Compared to the above listed vsock transports which are designed for high > performance, > > the main advantages of hypercall-vsock are: > > 1) It is VMM agnostic. For example, one guest working on hypercall-vsock > can run on > > either KVM, Hyperv, or VMware. hypercalls are fundamentally hypervisor dependent though. Assuming you can carve up a hypervisor independent hypercall, using it for something as mundane and specific as vsock for TDX seems like a huge overkill. For example, virtio could benefit from faster vmexits that hypercalls give you for signalling. How about a combination of virtio-mmio and hypercalls for fast-path signalling then? > 2) It is simpler. It doesn’t rely on any complex bus enumeration > > (e.g. virtio-pci based vsock device may need the whole implementation of PCI). > Next thing people will try to do is implement a bunch of other device on top of it. virtio used pci simply because everyone implements pci. And the reason for *that* is because implementing a basic pci bus is dead simple, whole of pci.c in qemu is <3000 LOC. > > An example usage is the communication between MigTD and host (Page 8 at > > https://static.sched.com/hosted_files/kvmforum2021/ef/ > TDX%20Live%20Migration_Wei%20Wang.pdf). > > MigTD communicates to host to assist the migration of the target (user) TD. > > MigTD is part of the TCB, so its implementation is expected to be as simple as > possible > > (e.g. bare mental implementation without OS, no PCI driver support). > > Try to list drawbacks? For example, passthrough for nested virt isn't possible unlike pci, neither are hardware implementations. > Looking forward to your feedbacks. > > > > Thanks, > > Wei > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 8/9] drm/simpledrm: Support virtual screen sizes
Add constants for the maximum size of the shadow-plane surface size. Useful for shadow planes with virtual screen sizes. The current sizes are 4096 scanlines with 4096 pixels each. This seems reasonable for current hardware, but can be increased as necessary. In simpledrm, set the maximum framebuffer size from the constants for shadow planes. Implements support for virtual screen sizes and page flipping on the fbdev console. v3: * use decimal numbers for shadow-plane constants (Noralf) Signed-off-by: Thomas Zimmermann Acked-by: Noralf Trønnes --- drivers/gpu/drm/tiny/simpledrm.c| 9 +++-- include/drm/drm_gem_atomic_helper.h | 18 ++ 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c index 7c7d0aca8e31..2f15b9aa 100644 --- a/drivers/gpu/drm/tiny/simpledrm.c +++ b/drivers/gpu/drm/tiny/simpledrm.c @@ -2,6 +2,7 @@ #include #include +#include #include #include #include @@ -772,6 +773,7 @@ static int simpledrm_device_init_modeset(struct simpledrm_device *sdev) struct drm_display_mode *mode = &sdev->mode; struct drm_connector *connector = &sdev->connector; struct drm_simple_display_pipe *pipe = &sdev->pipe; + unsigned long max_width, max_height; const uint32_t *formats; size_t nformats; int ret; @@ -780,10 +782,13 @@ static int simpledrm_device_init_modeset(struct simpledrm_device *sdev) if (ret) return ret; + max_width = max_t(unsigned long, mode->hdisplay, DRM_SHADOW_PLANE_MAX_WIDTH); + max_height = max_t(unsigned long, mode->vdisplay, DRM_SHADOW_PLANE_MAX_HEIGHT); + dev->mode_config.min_width = mode->hdisplay; - dev->mode_config.max_width = mode->hdisplay; + dev->mode_config.max_width = max_width; dev->mode_config.min_height = mode->vdisplay; - dev->mode_config.max_height = mode->vdisplay; + dev->mode_config.max_height = max_height; dev->mode_config.prefer_shadow_fbdev = true; dev->mode_config.preferred_depth = sdev->format->cpp[0] * 8; dev->mode_config.funcs = &simpledrm_mode_config_funcs; diff --git a/include/drm/drm_gem_atomic_helper.h b/include/drm/drm_gem_atomic_helper.h index 48222a107873..0b1e2dd2ac3f 100644 --- a/include/drm/drm_gem_atomic_helper.h +++ b/include/drm/drm_gem_atomic_helper.h @@ -22,6 +22,24 @@ int drm_gem_simple_display_pipe_prepare_fb(struct drm_simple_display_pipe *pipe, * Helpers for planes with shadow buffers */ +/** + * DRM_SHADOW_PLANE_MAX_WIDTH - Maximum width of a plane's shadow buffer in pixels + * + * For drivers with shadow planes, the maximum width of the framebuffer is + * usually independent from hardware limitations. Drivers can initialize struct + * drm_mode_config.max_width from DRM_SHADOW_PLANE_MAX_WIDTH. + */ +#define DRM_SHADOW_PLANE_MAX_WIDTH (4096u) + +/** + * DRM_SHADOW_PLANE_MAX_HEIGHT - Maximum height of a plane's shadow buffer in scanlines + * + * For drivers with shadow planes, the maximum height of the framebuffer is + * usually independent from hardware limitations. Drivers can initialize struct + * drm_mode_config.max_height from DRM_SHADOW_PLANE_MAX_HEIGHT. + */ +#define DRM_SHADOW_PLANE_MAX_HEIGHT(4096u) + /** * struct drm_shadow_plane_state - plane state for planes with shadow buffers * -- 2.33.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 6/9] drm/fb-helper: Allocate shadow buffer of surface height
Allocating a shadow buffer of the height of the buffer object does not support fbdev overallocation. Use surface height instead. Signed-off-by: Thomas Zimmermann Reviewed-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 8e7a124d6c5a..9727a59d35fd 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -2338,7 +2338,7 @@ static int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper, return PTR_ERR(fbi); fbi->fbops = &drm_fbdev_fb_ops; - fbi->screen_size = fb->height * fb->pitches[0]; + fbi->screen_size = sizes->surface_height * fb->pitches[0]; fbi->fix.smem_len = fbi->screen_size; drm_fb_helper_fill_info(fbi, fb_helper, sizes); -- 2.33.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 7/9] drm/simpledrm: Enable FB_DAMAGE_CLIPS property
Enable the FB_DAMAGE_CLIPS property to reduce display-update overhead. Also fixes a warning in the kernel log. simple-framebuffer simple-framebuffer.0: [drm] drm_plane_enable_fb_damage_clips() not called Fix the computation of the blit rectangle. This wasn't an issue so far, as simpledrm always blitted the full framebuffer. The code now supports damage clipping and virtual screen sizes. v3: * fix drm_dev_enter() error path (Noralf) * remove unnecessary clipping from update function (Noralf) Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/tiny/simpledrm.c | 28 +++- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c index 571f716ff427..7c7d0aca8e31 100644 --- a/drivers/gpu/drm/tiny/simpledrm.c +++ b/drivers/gpu/drm/tiny/simpledrm.c @@ -642,19 +642,23 @@ simpledrm_simple_display_pipe_enable(struct drm_simple_display_pipe *pipe, void *vmap = shadow_plane_state->data[0].vaddr; /* TODO: Use mapping abstraction */ struct drm_device *dev = &sdev->dev; void __iomem *dst = sdev->screen_base; - struct drm_rect clip; + struct drm_rect src_clip, dst_clip; int idx; if (!fb) return; - if (!drm_dev_enter(dev, &idx)) + drm_rect_fp_to_int(&src_clip, &plane_state->src); + + dst_clip = plane_state->dst; + if (!drm_rect_intersect(&dst_clip, &src_clip)) return; - drm_rect_init(&clip, 0, 0, fb->width, fb->height); + if (!drm_dev_enter(dev, &idx)) + return; - dst += drm_fb_clip_offset(sdev->pitch, sdev->format, &clip); - drm_fb_blit_toio(dst, sdev->pitch, sdev->format->format, vmap, fb, &clip); + dst += drm_fb_clip_offset(sdev->pitch, sdev->format, &dst_clip); + drm_fb_blit_toio(dst, sdev->pitch, sdev->format->format, vmap, fb, &src_clip); drm_dev_exit(idx); } @@ -686,20 +690,24 @@ simpledrm_simple_display_pipe_update(struct drm_simple_display_pipe *pipe, struct drm_framebuffer *fb = plane_state->fb; struct drm_device *dev = &sdev->dev; void __iomem *dst = sdev->screen_base; - struct drm_rect clip; + struct drm_rect src_clip, dst_clip; int idx; if (!fb) return; - if (!drm_atomic_helper_damage_merged(old_plane_state, plane_state, &clip)) + if (!drm_atomic_helper_damage_merged(old_plane_state, plane_state, &src_clip)) + return; + + dst_clip = plane_state->dst; + if (!drm_rect_intersect(&dst_clip, &src_clip)) return; if (!drm_dev_enter(dev, &idx)) return; - dst += drm_fb_clip_offset(sdev->pitch, sdev->format, &clip); - drm_fb_blit_toio(dst, sdev->pitch, sdev->format->format, vmap, fb, &clip); + dst += drm_fb_clip_offset(sdev->pitch, sdev->format, &dst_clip); + drm_fb_blit_toio(dst, sdev->pitch, sdev->format->format, vmap, fb, &src_clip); drm_dev_exit(idx); } @@ -794,6 +802,8 @@ static int simpledrm_device_init_modeset(struct simpledrm_device *sdev) if (ret) return ret; + drm_plane_enable_fb_damage_clips(&pipe->plane); + drm_mode_config_reset(dev); return 0; -- 2.33.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 9/9] drm: Clarify semantics of struct drm_mode_config.{min, max}_{width, height}
Add additional information on the semantics of the size fields in
struct drm_mode_config. Also add a TODO to review all driver for
correct usage of these fields.
Signed-off-by: Thomas Zimmermann
Acked-by: Noralf Trønnes
---
Documentation/gpu/todo.rst| 15 +++
include/drm/drm_mode_config.h | 13 +
2 files changed, 28 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 60d1d7ee0719..f4e1d72149f7 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -463,6 +463,21 @@ Contact: Thomas Zimmermann ,
Christian König, Daniel Vette
Level: Intermediate
+Review all drivers for setting struct drm_mode_config.{max_width,max_height}
correctly
+--
+
+The values in struct drm_mode_config.{max_width,max_height} describe the
+maximum supported framebuffer size. It's the virtual screen size, but many
+drivers treat it like limitations of the physical resolution.
+
+The maximum width depends on the hardware's maximum scanline pitch. The
+maximum height depends on the amount of addressable video memory. Review all
+drivers to initialize the fields to the correct values.
+
+Contact: Thomas Zimmermann
+
+Level: Intermediate
+
Core refactorings
=
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 48b7de80daf5..91ca575a78de 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -359,6 +359,19 @@ struct drm_mode_config_funcs {
* Core mode resource tracking structure. All CRTC, encoders, and connectors
* enumerated by the driver are added here, as are global properties. Some
* global restrictions are also here, e.g. dimension restrictions.
+ *
+ * Framebuffer sizes refer to the virtual screen that can be displayed by
+ * the CRTC. This can be different from the physical resolution programmed.
+ * The minimum width and height, stored in @min_width and @min_height,
+ * describe the smallest size of the framebuffer. It correlates to the
+ * minimum programmable resolution.
+ * The maximum width, stored in @max_width, is typically limited by the
+ * maximum pitch between two adjacent scanlines. The maximum height, stored
+ * in @max_height, is usually only limited by the amount of addressable video
+ * memory. For hardware that has no real maximum, drivers should pick a
+ * reasonable default.
+ *
+ * See also @DRM_SHADOW_PLANE_MAX_WIDTH and @DRM_SHADOW_PLANE_MAX_HEIGHT.
*/
struct drm_mode_config {
/**
--
2.33.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 5/9] drm/format-helper: Streamline blit-helper interface
Move destination-buffer clipping from format-helper blit function into
caller. Rename drm_fb_blit_rect_dstclip() to drm_fb_blit_toio(). Done for
consistency with the rest of the interface. Remove drm_fb_blit_dstclip(),
which isn't required.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Noralf Trønnes
---
drivers/gpu/drm/drm_format_helper.c | 51 -
drivers/gpu/drm/tiny/simpledrm.c| 14 +---
include/drm/drm_format_helper.h | 10 ++
3 files changed, 19 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 0c8933390fdd..2fd5098d5b55 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -472,7 +472,7 @@ void drm_fb_xrgb_to_gray8(void *dst, unsigned int
dst_pitch, const void *vad
EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
/**
- * drm_fb_blit_rect_dstclip - Copy parts of a framebuffer to display memory
+ * drm_fb_blit_toio - Copy parts of a framebuffer to display memory
* @dst: The display memory to copy to
* @dst_pitch: Number of bytes between two consecutive scanlines within dst
* @dst_format:FOURCC code of the display's color format
@@ -484,17 +484,14 @@ EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
* formats of the display and the framebuffer mismatch, the blit function
* will attempt to convert between them.
*
- * Use drm_fb_blit_dstclip() to copy the full framebuffer.
- *
* Returns:
* 0 on success, or
* -EINVAL if the color-format conversion failed, or
* a negative error code otherwise.
*/
-int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned int dst_pitch,
-uint32_t dst_format, void *vmap,
-struct drm_framebuffer *fb,
-struct drm_rect *clip)
+int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t
dst_format,
+const void *vmap, const struct drm_framebuffer *fb,
+const struct drm_rect *clip)
{
uint32_t fb_format = fb->format->format;
@@ -505,20 +502,16 @@ int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned
int dst_pitch,
dst_format = DRM_FORMAT_XRGB;
if (dst_format == fb_format) {
- dst += clip_offset(clip, dst_pitch, fb->format->cpp[0]);
drm_fb_memcpy_toio(dst, dst_pitch, vmap, fb, clip);
return 0;
} else if (dst_format == DRM_FORMAT_RGB565) {
if (fb_format == DRM_FORMAT_XRGB) {
- dst += clip_offset(clip, dst_pitch, fb->format->cpp[0]);
- drm_fb_xrgb_to_rgb565_toio(dst, dst_pitch, vmap,
fb, clip,
- false);
+ drm_fb_xrgb_to_rgb565_toio(dst, dst_pitch, vmap,
fb, clip, false);
return 0;
}
} else if (dst_format == DRM_FORMAT_RGB888) {
if (fb_format == DRM_FORMAT_XRGB) {
- dst += clip_offset(clip, dst_pitch, fb->format->cpp[0]);
drm_fb_xrgb_to_rgb888_toio(dst, dst_pitch, vmap,
fb, clip);
return 0;
}
@@ -526,36 +519,4 @@ int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned
int dst_pitch,
return -EINVAL;
}
-EXPORT_SYMBOL(drm_fb_blit_rect_dstclip);
-
-/**
- * drm_fb_blit_dstclip - Copy framebuffer to display memory
- * @dst: The display memory to copy to
- * @dst_pitch: Number of bytes between two consecutive scanlines within dst
- * @dst_format:FOURCC code of the display's color format
- * @vmap: The framebuffer memory to copy from
- * @fb:The framebuffer to copy from
- *
- * This function copies a full framebuffer to display memory. If the formats
- * of the display and the framebuffer mismatch, the copy function will
- * attempt to convert between them.
- *
- * See drm_fb_blit_rect_dstclip() for more information.
- *
- * Returns:
- * 0 on success, or a negative error code otherwise.
- */
-int drm_fb_blit_dstclip(void __iomem *dst, unsigned int dst_pitch,
- uint32_t dst_format, void *vmap,
- struct drm_framebuffer *fb)
-{
- struct drm_rect fullscreen = {
- .x1 = 0,
- .x2 = fb->width,
- .y1 = 0,
- .y2 = fb->height,
- };
- return drm_fb_blit_rect_dstclip(dst, dst_pitch, dst_format, vmap, fb,
- &fullscreen);
-}
-EXPORT_SYMBOL(drm_fb_blit_dstclip);
+EXPORT_SYMBOL(drm_fb_blit_toio);
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 481b48bde047..571f716ff427 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -641,6 +641,8 @@ simpledrm_simple_display_pipe_enable(struct
drm_simple_display_pipe *pipe,
[PATCH v3 2/9] drm/format-helper: Rework format-helper memcpy functions
Move destination-buffer clipping from all format-helper memcpy
function into callers. Support destination-buffer pitch. Only
distinguish between system and I/O memory, but use same logic
everywhere.
Signed-off-by: Thomas Zimmermann
Tested-by: Noralf Trønnes
Reviewed-by: Noralf Trønnes
---
drivers/gpu/drm/drm_format_helper.c | 35 -
drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
drivers/gpu/drm/gud/gud_pipe.c | 2 +-
drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 5 ++-
drivers/gpu/drm/mgag200/mgag200_mode.c | 4 ++-
drivers/gpu/drm/tiny/cirrus.c | 14 +
include/drm/drm_format_helper.h | 9 +++---
7 files changed, 41 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 677e62e39f72..fac37c697d8b 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -41,58 +41,62 @@ EXPORT_SYMBOL(drm_fb_clip_offset);
/**
* drm_fb_memcpy - Copy clip buffer
* @dst: Destination buffer
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
* @vaddr: Source buffer
* @fb: DRM framebuffer
* @clip: Clip rectangle area to copy
*
* This function does not apply clipping on dst, i.e. the destination
- * is a small buffer containing the clip rect only.
+ * is at the top-left corner.
*/
-void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
- struct drm_rect *clip)
+void drm_fb_memcpy(void *dst, unsigned int dst_pitch, const void *vaddr,
+ const struct drm_framebuffer *fb, const struct drm_rect
*clip)
{
unsigned int cpp = fb->format->cpp[0];
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y, lines = clip->y2 - clip->y1;
+ if (!dst_pitch)
+ dst_pitch = len;
+
vaddr += clip_offset(clip, fb->pitches[0], cpp);
for (y = 0; y < lines; y++) {
memcpy(dst, vaddr, len);
vaddr += fb->pitches[0];
- dst += len;
+ dst += dst_pitch;
}
}
EXPORT_SYMBOL(drm_fb_memcpy);
/**
- * drm_fb_memcpy_dstclip - Copy clip buffer
+ * drm_fb_memcpy_toio - Copy clip buffer
* @dst: Destination buffer (iomem)
* @dst_pitch: Number of bytes between two consecutive scanlines within dst
* @vaddr: Source buffer
* @fb: DRM framebuffer
* @clip: Clip rectangle area to copy
*
- * This function applies clipping on dst, i.e. the destination is a
- * full (iomem) framebuffer but only the clip rect content is copied over.
+ * This function does not apply clipping on dst, i.e. the destination
+ * is at the top-left corner.
*/
-void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch,
- void *vaddr, struct drm_framebuffer *fb,
- struct drm_rect *clip)
+void drm_fb_memcpy_toio(void __iomem *dst, unsigned int dst_pitch, const void
*vaddr,
+ const struct drm_framebuffer *fb, const struct drm_rect
*clip)
{
unsigned int cpp = fb->format->cpp[0];
- unsigned int offset = clip_offset(clip, dst_pitch, cpp);
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y, lines = clip->y2 - clip->y1;
- vaddr += offset;
- dst += offset;
+ if (!dst_pitch)
+ dst_pitch = len;
+
+ vaddr += clip_offset(clip, fb->pitches[0], cpp);
for (y = 0; y < lines; y++) {
memcpy_toio(dst, vaddr, len);
vaddr += fb->pitches[0];
dst += dst_pitch;
}
}
-EXPORT_SYMBOL(drm_fb_memcpy_dstclip);
+EXPORT_SYMBOL(drm_fb_memcpy_toio);
/**
* drm_fb_swab - Swap bytes into clip buffer
@@ -481,7 +485,8 @@ int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned
int dst_pitch,
dst_format = DRM_FORMAT_XRGB;
if (dst_format == fb_format) {
- drm_fb_memcpy_dstclip(dst, dst_pitch, vmap, fb, clip);
+ dst += clip_offset(clip, dst_pitch, fb->format->cpp[0]);
+ drm_fb_memcpy_toio(dst, dst_pitch, vmap, fb, clip);
return 0;
} else if (dst_format == DRM_FORMAT_RGB565) {
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 71b646c4131f..c09df8b06c7a 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -213,7 +213,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
if (swap)
drm_fb_swab(dst, src, fb, clip, !gem->import_attach);
else
- drm_fb_memcpy(dst, src, fb, clip);
+ drm_fb_memcpy(dst, 0, src, fb, clip);
break;
case DRM_FORMAT_XRGB:
drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
index daf7
[PATCH v3 3/9] drm/format-helper: Add destination-buffer pitch to drm_fb_swab()
Add destination-buffer pitch as argument to drm_fb_swab(). Done for
consistency with the rest of the interface.
v2:
* update documentation (Noralf)
Signed-off-by: Thomas Zimmermann
Tested-by: Noralf Trønnes
Reviewed-by: Noralf Trønnes
---
drivers/gpu/drm/drm_format_helper.c | 21 -
drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
drivers/gpu/drm/gud/gud_pipe.c | 2 +-
include/drm/drm_format_helper.h | 5 +++--
4 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index fac37c697d8b..dac355320287 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -101,6 +101,7 @@ EXPORT_SYMBOL(drm_fb_memcpy_toio);
/**
* drm_fb_swab - Swap bytes into clip buffer
* @dst: Destination buffer
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
* @src: Source buffer
* @fb: DRM framebuffer
* @clip: Clip rectangle area to copy
@@ -110,21 +111,27 @@ EXPORT_SYMBOL(drm_fb_memcpy_toio);
* time to speed up slow uncached reads.
*
* This function does not apply clipping on dst, i.e. the destination
- * is a small buffer containing the clip rect only.
+ * is at the top-left corner.
*/
-void drm_fb_swab(void *dst, void *src, struct drm_framebuffer *fb,
-struct drm_rect *clip, bool cached)
+void drm_fb_swab(void *dst, unsigned int dst_pitch, const void *src,
+const struct drm_framebuffer *fb, const struct drm_rect *clip,
+bool cached)
{
u8 cpp = fb->format->cpp[0];
size_t len = drm_rect_width(clip) * cpp;
- u16 *src16, *dst16 = dst;
- u32 *src32, *dst32 = dst;
+ const u16 *src16;
+ const u32 *src32;
+ u16 *dst16;
+ u32 *dst32;
unsigned int x, y;
void *buf = NULL;
if (WARN_ON_ONCE(cpp != 2 && cpp != 4))
return;
+ if (!dst_pitch)
+ dst_pitch = len;
+
if (!cached)
buf = kmalloc(len, GFP_KERNEL);
@@ -140,6 +147,9 @@ void drm_fb_swab(void *dst, void *src, struct
drm_framebuffer *fb,
src32 = src;
}
+ dst16 = dst;
+ dst32 = dst;
+
for (x = clip->x1; x < clip->x2; x++) {
if (cpp == 4)
*dst32++ = swab32(*src32++);
@@ -148,6 +158,7 @@ void drm_fb_swab(void *dst, void *src, struct
drm_framebuffer *fb,
}
src += fb->pitches[0];
+ dst += dst_pitch;
}
kfree(buf);
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index c09df8b06c7a..7ce89917d761 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -211,7 +211,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
switch (fb->format->format) {
case DRM_FORMAT_RGB565:
if (swap)
- drm_fb_swab(dst, src, fb, clip, !gem->import_attach);
+ drm_fb_swab(dst, 0, src, fb, clip, !gem->import_attach);
else
drm_fb_memcpy(dst, 0, src, fb, clip);
break;
diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
index a92112ffd37a..e0b117b2559f 100644
--- a/drivers/gpu/drm/gud/gud_pipe.c
+++ b/drivers/gpu/drm/gud/gud_pipe.c
@@ -201,7 +201,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
drm_framebuffer *fb,
len = gud_xrgb_to_color(buf, format, vaddr, fb,
rect);
}
} else if (gud_is_big_endian() && format->cpp[0] > 1) {
- drm_fb_swab(buf, vaddr, fb, rect, !import_attach);
+ drm_fb_swab(buf, 0, vaddr, fb, rect, !import_attach);
} else if (compression && !import_attach && pitch == fb->pitches[0]) {
/* can compress directly from the framebuffer */
buf = vaddr + rect->y1 * pitch;
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 1fc3ba7b6060..ddcba5abe306 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -17,8 +17,9 @@ void drm_fb_memcpy(void *dst, unsigned int dst_pitch, const
void *vaddr,
const struct drm_framebuffer *fb, const struct drm_rect
*clip);
void drm_fb_memcpy_toio(void __iomem *dst, unsigned int dst_pitch, const void
*vaddr,
const struct drm_framebuffer *fb, const struct drm_rect
*clip);
-void drm_fb_swab(void *dst, void *src, struct drm_framebuffer *fb,
-struct drm_rect *clip, bool cached);
+void drm_fb_swab(void *dst, unsigned int dst_pitch, const void *src,
+const struct drm_framebuffer *fb, const struct drm_rect *clip,
+bool cached);
void drm_fb_xrgb_to_rgb332(void *dst, void *vaddr, struct drm
[PATCH v3 4/9] drm/format-helper: Rework format-helper conversion functions
Move destination-buffer clipping from all format-helper conversion
functions into callers. Support destination-buffer pitch. Only
distinguish between system and I/O memory, but use same logic
everywhere.
Simply harmonize the interface and semantics of the existing code.
Not all conversion helpers support all combinations of parameters.
We have to add additional features when we need them.
v2:
* fix default destination pitch in drm_fb_xrgb_to_gray8()
(Noralf)
Signed-off-by: Thomas Zimmermann
Tested-by: Noralf Trønnes
Reviewed-by: Noralf Trønnes
---
drivers/gpu/drm/drm_format_helper.c | 131 +++-
drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
drivers/gpu/drm/gud/gud_pipe.c | 10 +--
drivers/gpu/drm/tiny/cirrus.c | 10 +--
drivers/gpu/drm/tiny/repaper.c | 2 +-
drivers/gpu/drm/tiny/st7586.c | 2 +-
include/drm/drm_format_helper.h | 30 +++
7 files changed, 97 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index dac355320287..0c8933390fdd 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -165,7 +165,7 @@ void drm_fb_swab(void *dst, unsigned int dst_pitch, const
void *src,
}
EXPORT_SYMBOL(drm_fb_swab);
-static void drm_fb_xrgb_to_rgb332_line(u8 *dbuf, __le32 *sbuf, unsigned
int pixels)
+static void drm_fb_xrgb_to_rgb332_line(u8 *dbuf, const __le32 *sbuf,
unsigned int pixels)
{
unsigned int x;
u32 pix;
@@ -181,23 +181,24 @@ static void drm_fb_xrgb_to_rgb332_line(u8 *dbuf,
__le32 *sbuf, unsigned int
/**
* drm_fb_xrgb_to_rgb332 - Convert XRGB to RGB332 clip buffer
* @dst: RGB332 destination buffer
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
* @src: XRGB source buffer
* @fb: DRM framebuffer
* @clip: Clip rectangle area to copy
*
* Drivers can use this function for RGB332 devices that don't natively
support XRGB.
- *
- * This function does not apply clipping on dst, i.e. the destination is a
small buffer
- * containing the clip rect only.
*/
-void drm_fb_xrgb_to_rgb332(void *dst, void *src, struct drm_framebuffer
*fb,
- struct drm_rect *clip)
+void drm_fb_xrgb_to_rgb332(void *dst, unsigned int dst_pitch, const void
*src,
+ const struct drm_framebuffer *fb, const struct
drm_rect *clip)
{
size_t width = drm_rect_width(clip);
size_t src_len = width * sizeof(u32);
unsigned int y;
void *sbuf;
+ if (!dst_pitch)
+ dst_pitch = width;
+
/* Use a buffer to speed up access on buffers with uncached read
mapping (i.e. WC) */
sbuf = kmalloc(src_len, GFP_KERNEL);
if (!sbuf)
@@ -208,14 +209,14 @@ void drm_fb_xrgb_to_rgb332(void *dst, void *src,
struct drm_framebuffer *fb,
memcpy(sbuf, src, src_len);
drm_fb_xrgb_to_rgb332_line(dst, sbuf, width);
src += fb->pitches[0];
- dst += width;
+ dst += dst_pitch;
}
kfree(sbuf);
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb332);
-static void drm_fb_xrgb_to_rgb565_line(u16 *dbuf, u32 *sbuf,
+static void drm_fb_xrgb_to_rgb565_line(u16 *dbuf, const u32 *sbuf,
unsigned int pixels,
bool swab)
{
@@ -236,6 +237,7 @@ static void drm_fb_xrgb_to_rgb565_line(u16 *dbuf, u32
*sbuf,
/**
* drm_fb_xrgb_to_rgb565 - Convert XRGB to RGB565 clip buffer
* @dst: RGB565 destination buffer
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
* @vaddr: XRGB source buffer
* @fb: DRM framebuffer
* @clip: Clip rectangle area to copy
@@ -243,13 +245,10 @@ static void drm_fb_xrgb_to_rgb565_line(u16 *dbuf, u32
*sbuf,
*
* Drivers can use this function for RGB565 devices that don't natively
* support XRGB.
- *
- * This function does not apply clipping on dst, i.e. the destination
- * is a small buffer containing the clip rect only.
*/
-void drm_fb_xrgb_to_rgb565(void *dst, void *vaddr,
- struct drm_framebuffer *fb,
- struct drm_rect *clip, bool swab)
+void drm_fb_xrgb_to_rgb565(void *dst, unsigned int dst_pitch, const void
*vaddr,
+ const struct drm_framebuffer *fb, const struct
drm_rect *clip,
+ bool swab)
{
size_t linepixels = clip->x2 - clip->x1;
size_t src_len = linepixels * sizeof(u32);
@@ -257,6 +256,9 @@ void drm_fb_xrgb_to_rgb565(void *dst, void *vaddr,
unsigned y, lines = clip->y2 - clip->y1;
void *sbuf;
+ if (!dst_pitch)
+ dst_pitch = dst_len;
+
/*
* The cma memory is write-combined so reads are uncached.
[PATCH v3 1/9] drm/format-helper: Export drm_fb_clip_offset()
Provide a function that computes the offset into a blit destination
buffer. This will allow to move destination-buffer clipping into the
format-helper callers.
v2:
* provide documentation (Sam)
* return 'unsigned int' (Sam, Noralf)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Noralf Trønnes
---
drivers/gpu/drm/drm_format_helper.c | 19 +--
include/drm/drm_format_helper.h | 4
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 69fde60e36b3..677e62e39f72 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -17,12 +17,27 @@
#include
#include
-static unsigned int clip_offset(struct drm_rect *clip,
- unsigned int pitch, unsigned int cpp)
+static unsigned int clip_offset(const struct drm_rect *clip, unsigned int
pitch, unsigned int cpp)
{
return clip->y1 * pitch + clip->x1 * cpp;
}
+/**
+ * drm_fb_clip_offset - Returns the clipping rectangles byte-offset in a
frambuffer
+ * pitch: Frambuffer line pitch in byte
+ * format: Frambuffer format
+ * clip: Clip rectangle
+ *
+ * Returns:
+ * The byte offset of the clip rectangle's top-left corner within the
framebuffer.
+ */
+unsigned int drm_fb_clip_offset(unsigned int pitch, const struct
drm_format_info *format,
+ const struct drm_rect *clip)
+{
+ return clip_offset(clip, pitch, format->cpp[0]);
+}
+EXPORT_SYMBOL(drm_fb_clip_offset);
+
/**
* drm_fb_memcpy - Copy clip buffer
* @dst: Destination buffer
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index e86925cf07b9..f5a8b334b18d 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -6,9 +6,13 @@
#ifndef __LINUX_DRM_FORMAT_HELPER_H
#define __LINUX_DRM_FORMAT_HELPER_H
+struct drm_format_info;
struct drm_framebuffer;
struct drm_rect;
+unsigned int drm_fb_clip_offset(unsigned int pitch, const struct
drm_format_info *format,
+ const struct drm_rect *clip);
+
void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch, void
*vaddr,
--
2.33.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 0/9] drm/simpledrm: Enable damage clips and virtual screens
Enable FB_DAMAGE_CLIPS with simpledrm for improved performance and/or
less overhead. With this in place, add support for virtual screens
(i.e., framebuffers that are larger than the display resolution). This
also enables fbdev panning and page flipping.
After the discussion and bug fixing wrt to fbdev overallocation, I
decided to add full support for this to simpledrm. Patches #1 to #5
change the format-helper functions accordingly. Destination buffers
are now clipped by the caller and all functions support a similar
feature set. This has some fallout in various drivers.
Patch #6 change fbdev emulation to support overallocation with
shadow buffers, even if the hardware buffer would be too small.
Patch #7 and #8 update simpledrm to enable damage clipping and virtual
screen sizes. Both features go hand in hand, sort of. For shadow-
buffered planes, the DRM framebuffer lives in system memory. So the
maximum size of the virtual screen is somewhat arbitrary. We add two
constants for resonable maximum width and height of 4096 each.
Patch #9 adds documentation and a TODO item.
Tested with simpledrm. I also ran the recently posted fbdev panning
tests to make sure that the fbdev overallocation works correctly. [1]
v3:
* remove unnecessary clipping in simpledrm (Noralf)
* fix drm_dev_enter() usage (Noralf)
* style changes (Noralf)
v2:
* add missing docs (Sam)
* return unsigned int from drm_fb_clip_offset() (Sam, Noralf)
* fix OOB access in drm_fb_xrgb_to_gray8() (Noralf)
[1] https://lists.freedesktop.org/archives/igt-dev/2021-October/036642.html
Thomas Zimmermann (9):
drm/format-helper: Export drm_fb_clip_offset()
drm/format-helper: Rework format-helper memcpy functions
drm/format-helper: Add destination-buffer pitch to drm_fb_swab()
drm/format-helper: Rework format-helper conversion functions
drm/format-helper: Streamline blit-helper interface
drm/fb-helper: Allocate shadow buffer of surface height
drm/simpledrm: Enable FB_DAMAGE_CLIPS property
drm/simpledrm: Support virtual screen sizes
drm: Clarify semantics of struct
drm_mode_config.{min,max}_{width,height}
Documentation/gpu/todo.rst | 15 ++
drivers/gpu/drm/drm_fb_helper.c | 2 +-
drivers/gpu/drm/drm_format_helper.c | 247 ++--
drivers/gpu/drm/drm_mipi_dbi.c | 6 +-
drivers/gpu/drm/gud/gud_pipe.c | 14 +-
drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 5 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 4 +-
drivers/gpu/drm/tiny/cirrus.c | 24 +-
drivers/gpu/drm/tiny/repaper.c | 2 +-
drivers/gpu/drm/tiny/simpledrm.c| 37 ++-
drivers/gpu/drm/tiny/st7586.c | 2 +-
include/drm/drm_format_helper.h | 58 ++---
include/drm/drm_gem_atomic_helper.h | 18 ++
include/drm/drm_mode_config.h | 13 ++
14 files changed, 260 insertions(+), 187 deletions(-)
base-commit: 215295e7b0a3deb2015c6d6b343b319e4f6d9a1d
prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
--
2.33.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC] hypercall-vsock: add a new vsock transport
On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote: > We plan to add a new vsock transport based on hypercall (e.g. vmcall on Intel > CPUs). > It transports AF_VSOCK packets between the guest and host, which is similar to > virtio-vsock, vmci-vsock and hyperv-vsock. > > Compared to the above listed vsock transports which are designed for high > performance, > the main advantages of hypercall-vsock are: > > 1) It is VMM agnostic. For example, one guest working on > hypercall-vsock can run on > > either KVM, Hyperv, or VMware. > > 2) It is simpler. It doesn't rely on any complex bus enumeration > > (e.g. virtio-pci based vsock device may need the whole implementation of PCI). > > An example usage is the communication between MigTD and host (Page 8 at > https://static.sched.com/hosted_files/kvmforum2021/ef/TDX%20Live%20Migration_Wei%20Wang.pdf). > MigTD communicates to host to assist the migration of the target (user) TD. > MigTD is part of the TCB, so its implementation is expected to be as simple > as possible > (e.g. bare mental implementation without OS, no PCI driver support). AF_VSOCK is designed to allow multiple transports, so why not. There is a cost to developing and maintaining a vsock transport though. I think Amazon Nitro enclaves use virtio-vsock and I've CCed Andra in case she has thoughts on the pros/cons and how to minimize the trusted computing base. If simplicity is the top priority then VIRTIO's MMIO transport without indirect descriptors and using the packed virtqueue layout reduces the size of the implementation: https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-1440002 Stefan signature.asc Description: PGP signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 3/9] drm/format-helper: Add destination-buffer pitch to drm_fb_swab()
Am 08.11.21 um 19:57 schrieb Amanoel Dawod:
Hi,
On Mon, Nov 1, 2021, at 10:15 AM, Thomas Zimmermann wrote:
Add destination-buffer pitch as argument to drm_fb_swab(). Done for
consistency with the rest of the interface.
v2:
* update documentation (Noralf)
Signed-off-by: Thomas Zimmermann
Tested-by: Noralf Trønnes
Reviewed-by: Noralf Trønnes
---
drivers/gpu/drm/drm_format_helper.c | 21 -
drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
drivers/gpu/drm/gud/gud_pipe.c | 2 +-
include/drm/drm_format_helper.h | 5 +++--
4 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index fac37c697d8b..dac355320287 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -101,6 +101,7 @@ EXPORT_SYMBOL(drm_fb_memcpy_toio);
/**
* drm_fb_swab - Swap bytes into clip buffer
* @dst: Destination buffer
+ * @dst_pitch: Number of bytes between two consecutive scanlines
within dst
* @src: Source buffer
* @fb: DRM framebuffer
* @clip: Clip rectangle area to copy
@@ -110,21 +111,27 @@ EXPORT_SYMBOL(drm_fb_memcpy_toio);
* time to speed up slow uncached reads.
*
* This function does not apply clipping on dst, i.e. the destination
- * is a small buffer containing the clip rect only.
+ * is at the top-left corner.
*/
-void drm_fb_swab(void *dst, void *src, struct drm_framebuffer *fb,
-struct drm_rect *clip, bool cached)
+void drm_fb_swab(void *dst, unsigned int dst_pitch, const void *src,
+const struct drm_framebuffer *fb, const struct drm_rect *clip,
+bool cached)
{
u8 cpp = fb->format->cpp[0];
size_t len = drm_rect_width(clip) * cpp;
- u16 *src16, *dst16 = dst;
- u32 *src32, *dst32 = dst;
+ const u16 *src16;
+ const u32 *src32;
+ u16 *dst16;
+ u32 *dst32;
unsigned int x, y;
void *buf = NULL;
if (WARN_ON_ONCE(cpp != 2 && cpp != 4))
return;
+ if (!dst_pitch)
+ dst_pitch = len;
+
if (!cached)
buf = kmalloc(len, GFP_KERNEL);
@@ -140,6 +147,9 @@ void drm_fb_swab(void *dst, void *src, struct
drm_framebuffer *fb,
src32 = src;
}
+ dst16 = dst;
+ dst32 = dst;
+
for (x = clip->x1; x < clip->x2; x++) {
if (cpp == 4)
*dst32++ = swab32(*src32++);
@@ -148,6 +158,7 @@ void drm_fb_swab(void *dst, void *src, struct
drm_framebuffer *fb,
}
src += fb->pitches[0];
+ dst += dst_pitch;
}
kfree(buf);
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c
b/drivers/gpu/drm/drm_mipi_dbi.c
index c09df8b06c7a..7ce89917d761 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -211,7 +211,7 @@ int mipi_dbi_buf_copy(void *dst, struct
drm_framebuffer *fb,
switch (fb->format->format) {
case DRM_FORMAT_RGB565:
if (swap)
- drm_fb_swab(dst, src, fb, clip, !gem->import_attach);
+ drm_fb_swab(dst, 0, src, fb, clip, !gem->import_attach);
else
drm_fb_memcpy(dst, 0, src, fb, clip);
break;
diff --git a/drivers/gpu/drm/gud/gud_pipe.c
b/drivers/gpu/drm/gud/gud_pipe.c
index a92112ffd37a..e0b117b2559f 100644
--- a/drivers/gpu/drm/gud/gud_pipe.c
+++ b/drivers/gpu/drm/gud/gud_pipe.c
@@ -201,7 +201,7 @@ static int gud_prep_flush(struct gud_device *gdrm,
struct drm_framebuffer *fb,
len = gud_xrgb_to_color(buf, format, vaddr, fb,
rect);
}
} else if (gud_is_big_endian() && format->cpp[0] > 1) {
- drm_fb_swab(buf, vaddr, fb, rect, !import_attach);
+ drm_fb_swab(buf, 0, vaddr, fb, rect, !import_attach);
} else if (compression && !import_attach && pitch == fb->pitches[0]) {
/* can compress directly from the framebuffer */
buf = vaddr + rect->y1 * pitch;
diff --git a/include/drm/drm_format_helper.h
b/include/drm/drm_format_helper.h
index 1fc3ba7b6060..ddcba5abe306 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -17,8 +17,9 @@ void drm_fb_memcpy(void *dst, unsigned int dst_pitch,
const void *vaddr,
const struct drm_framebuffer *fb, const struct drm_rect
*clip);
void drm_fb_memcpy_toio(void __iomem *dst, unsigned int dst_pitch,
const void *vaddr,
const struct drm_framebuffer *fb, const struct drm_rect
*clip);
-void drm_fb_swab(void *dst, void *src, struct drm_framebuffer *fb,
-struct drm_rect *clip, bool cached);
+void drm_fb_swab(void *dst, unsigned int dst_pitch, const void *src,
+const struct drm_framebuffer *fb, const st
