[PATCH RESEND] VMCI: Check exclusive_vectors when freeing interrupt 1
From: Vishnu Dasa
free_irq() may be called to free an interrupt that was not
allocated. Add missing 'if' statement to check for
exclusive_vectors when freeing interrupt 1.
Fixes: cc68f2177fcb ("VMCI: dma dg: register dummy IRQ handlers for DMA
datagrams")
Reported-by: Dan Carpenter
Reviewed-by: Bryan Tan
Reviewed-by: Rajesh Jalisatgi
Signed-off-by: Vishnu Dasa
---
drivers/misc/vmw_vmci/vmci_guest.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index 6596a54daa88..57a6157209a1 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -862,7 +862,9 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
return 0;
err_free_bm_irq:
- free_irq(pci_irq_vector(pdev, 1), vmci_dev);
+ if (vmci_dev->exclusive_vectors)
+ free_irq(pci_irq_vector(pdev, 1), vmci_dev);
+
err_free_irq:
free_irq(pci_irq_vector(pdev, 0), vmci_dev);
tasklet_kill(_dev->datagram_tasklet);
--
2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v1 1/2] vdpa: Add support for querying vendor statistics
On Fri, Mar 18, 2022 at 8:59 AM Si-Wei Liu wrote: > > > > On 3/16/2022 7:32 PM, Jason Wang wrote: > > On Thu, Mar 17, 2022 at 6:00 AM Si-Wei Liu wrote: > >> > >> > >> On 3/16/2022 12:10 AM, Eli Cohen wrote: > From: Si-Wei Liu > Sent: Wednesday, March 16, 2022 8:52 AM > To: Eli Cohen > Cc: m...@redhat.com; jasow...@redhat.com; > virtualization@lists.linux-foundation.org; epere...@redhat.com; > amore...@redhat.com; > lviv...@redhat.com; sgarz...@redhat.com; Parav Pandit > Subject: Re: [PATCH v1 1/2] vdpa: Add support for querying vendor > statistics > > > > On 3/15/2022 2:10 AM, Eli Cohen wrote: > > <...snip...> > > >> Say you got a vdpa net device created with 4 data queue pairs and a > >> control vq. On boot some guest firmware may support just F_CTRL_VQ but > >> not F_MQ, then the index for the control vq in guest ends up with 2, as > >> in this case there's only a single queue pair enabled for rx (index 0) > >> and tx (index 1). From the host driver (e.g. mlx5_vdpa) perspective, > >> the > >> control vq is the last vq following 8 > > If the host sees F_MQ was not negotiated but F_CTRL_VQ was, then it > > knows > > that control VQ index is 2 > Right, but I don't see this feature negotiation info getting returned > from your vdpa_dev_vendor_stats_fill(), or did I miss something? How do > you plan for host user to get this info? If you meant another "vdpa dev > show" command to query negotiated features ahead, this won't get the > same lock protected as the time you run the stat query. It's very easy > to miss that ephemeral queue index. > >>> Right, so I suggested to include the negotiated features in the netlink > >>> message > >>> for the statistics. That would save us from using two system calls to get > >>> the > >>> information required and it answers your concern with respect to locking. > >>> I think Jason was reluctant to adding this attribute to the message but > >>> can't > >>> find where he explained the reasoning. > >> Maybe Jason can clarify and correct me, but I just did not get the same > >> impression as what you said? I just skimmed through all of the emails in > >> the thread, only finding that he didn't want device specific attribute > >> such as queue type to get returned by the vdpa core, which I agree. I'm > >> not sure if he's explicitly against piggyback negotiated features to aid > >> userspace parsing the index. > > I think we need piggyback the negotiated features, otherwise as you > > mentioned, we will probably get in-consistency. > Great. Thanks for confirming it. > > > > > But a question for the "host queue index", as mentioned before. It's > > something that is not defined in the spec, so technically, vendor can > > do any mappings between it and the index what guest can see. I feel > > like we need to clarify it in the spec first. > I have been thinking about this for some while today. Actually I am not > against exposing the host queue index to the spec, as we know it's > somewhat implicitly defined in the QEMU device model for multiqueue. The > thing is, I'm not sure if there's extra benefit than this minor > requirement (*) given that all of the other vDPA kAPI are taking the > guest queue index rather than the host queue index. Rethink of this, consider currently we do this via vendor stats, so it's probably fine. Maybe we can have a better netlink API like "vendor_queue_index" etc then everything should be fine. > It works for > mlx5_vdpa as the control vq is implemented in the software, so it can > map to whatever guest qindex it wishes to. But would it cause extra > trouble for some other emulated vDPA device or other vendor's vDPA such > as ifcvf to fabricate a fake mapping between the host queue index and > the one guest can see? I would have to send a heads-up ahead that the > current vhost-vdpa mq implementation in upstream QEMU has some issue in > mapping the host qindex to the guest one. This would become a problem > with MQ enabled vdpa device and a non-MQ supporting guest e.g. OVMF, for > which I'm about to share some RFC patches shortly to demonstrate the > issue. Sure. > If exposing the host queue index to the spec turns is essential > to resolving this issue and maybe help with software virtio QEMU > implementation too, I won't hesitate to expose this important > implementation detail to the spec. > > (*) another means that may somehow address my use case is to use some > magic keyword e.g. "ctrlvq" to identify the control vq. Implementation > wise, we can extensively pass -1 to indicate the last guest qindex to > the get_vq_vstat() API given that we know for sure the ctrlvq is the > last queue in the array when the relevant features are present. Since > the negotiated features are piggybacked, it's not hard for the vdpa tool > to tell apart whether the last queue is a control vq or not.
Re: [PATCH] virito-pci-modern: Remove useless DMA-32 fallback configuration
On Fri, Mar 18, 2022 at 8:59 AM wrote: > > From: Minghao Chi > > As stated in [1], dma_set_mask() with a 64-bit mask will never fail if > dev->dma_mask is non-NULL. > So, if it fails, the 32 bits case will also fail for the same reason. > > Simplify code and remove some dead code accordingly. > > [1]: https://lkml.org/lkml/2021/6/7/398 > > Reported-by: Zeal Robot > Signed-off-by: Minghao Chi > --- > drivers/virtio/virtio_pci_modern_dev.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/virtio/virtio_pci_modern_dev.c > b/drivers/virtio/virtio_pci_modern_dev.c > index e8b3ff2b9fbc..dff0b15a239d 100644 > --- a/drivers/virtio/virtio_pci_modern_dev.c > +++ b/drivers/virtio/virtio_pci_modern_dev.c > @@ -255,9 +255,6 @@ int vp_modern_probe(struct virtio_pci_modern_device *mdev) > } > > err = dma_set_mask_and_coherent(_dev->dev, DMA_BIT_MASK(64)); > - if (err) > - err = dma_set_mask_and_coherent(_dev->dev, > - DMA_BIT_MASK(32)); So we had: if (!dev->dma_mask || !dma_supported(dev, mask)) return -EIO; in dma_set_mask(), any reason dma_supported() can't be false here? Thanks > if (err) > dev_warn(_dev->dev, "Failed to enable 64-bit or 32-bit > DMA. Trying to continue, but this might not work.\n"); > > -- > 2.25.1 > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v1 1/2] vdpa: Add support for querying vendor statistics
On 3/16/2022 7:32 PM, Jason Wang wrote: On Thu, Mar 17, 2022 at 6:00 AM Si-Wei Liu wrote: On 3/16/2022 12:10 AM, Eli Cohen wrote: From: Si-Wei Liu Sent: Wednesday, March 16, 2022 8:52 AM To: Eli Cohen Cc: m...@redhat.com; jasow...@redhat.com; virtualization@lists.linux-foundation.org; epere...@redhat.com; amore...@redhat.com; lviv...@redhat.com; sgarz...@redhat.com; Parav Pandit Subject: Re: [PATCH v1 1/2] vdpa: Add support for querying vendor statistics On 3/15/2022 2:10 AM, Eli Cohen wrote: <...snip...> Say you got a vdpa net device created with 4 data queue pairs and a control vq. On boot some guest firmware may support just F_CTRL_VQ but not F_MQ, then the index for the control vq in guest ends up with 2, as in this case there's only a single queue pair enabled for rx (index 0) and tx (index 1). From the host driver (e.g. mlx5_vdpa) perspective, the control vq is the last vq following 8 If the host sees F_MQ was not negotiated but F_CTRL_VQ was, then it knows that control VQ index is 2 Right, but I don't see this feature negotiation info getting returned from your vdpa_dev_vendor_stats_fill(), or did I miss something? How do you plan for host user to get this info? If you meant another "vdpa dev show" command to query negotiated features ahead, this won't get the same lock protected as the time you run the stat query. It's very easy to miss that ephemeral queue index. Right, so I suggested to include the negotiated features in the netlink message for the statistics. That would save us from using two system calls to get the information required and it answers your concern with respect to locking. I think Jason was reluctant to adding this attribute to the message but can't find where he explained the reasoning. Maybe Jason can clarify and correct me, but I just did not get the same impression as what you said? I just skimmed through all of the emails in the thread, only finding that he didn't want device specific attribute such as queue type to get returned by the vdpa core, which I agree. I'm not sure if he's explicitly against piggyback negotiated features to aid userspace parsing the index. I think we need piggyback the negotiated features, otherwise as you mentioned, we will probably get in-consistency. Great. Thanks for confirming it. But a question for the "host queue index", as mentioned before. It's something that is not defined in the spec, so technically, vendor can do any mappings between it and the index what guest can see. I feel like we need to clarify it in the spec first. I have been thinking about this for some while today. Actually I am not against exposing the host queue index to the spec, as we know it's somewhat implicitly defined in the QEMU device model for multiqueue. The thing is, I'm not sure if there's extra benefit than this minor requirement (*) given that all of the other vDPA kAPI are taking the guest queue index rather than the host queue index. It works for mlx5_vdpa as the control vq is implemented in the software, so it can map to whatever guest qindex it wishes to. But would it cause extra trouble for some other emulated vDPA device or other vendor's vDPA such as ifcvf to fabricate a fake mapping between the host queue index and the one guest can see? I would have to send a heads-up ahead that the current vhost-vdpa mq implementation in upstream QEMU has some issue in mapping the host qindex to the guest one. This would become a problem with MQ enabled vdpa device and a non-MQ supporting guest e.g. OVMF, for which I'm about to share some RFC patches shortly to demonstrate the issue. If exposing the host queue index to the spec turns is essential to resolving this issue and maybe help with software virtio QEMU implementation too, I won't hesitate to expose this important implementation detail to the spec. (*) another means that may somehow address my use case is to use some magic keyword e.g. "ctrlvq" to identify the control vq. Implementation wise, we can extensively pass -1 to indicate the last guest qindex to the get_vq_vstat() API given that we know for sure the ctrlvq is the last queue in the array when the relevant features are present. Since the negotiated features are piggybacked, it's not hard for the vdpa tool to tell apart whether the last queue is a control vq or not. I'd also welcome other ideas that can make virtqueue identification easier and predictable from the CLI. Thanks, -Siwei Thanks Another way around, vdpa tool may pass down -1 to get_vq_vstat() to represent the queue index for the control queue - but that's less favorable as the vdpa core needs to maintain device specific knowledge. data vqs of all 4 pairs, hence got the 8th index in the rank. Since F_MQ is not negotiated and only 1 data queue pair enabled, in such event only host qindex 0,1 and 8 have vendor stats available, and the rest of qindex would get invalid/empty stat. Later on say boot continues towards loading the
Re: [PATCH 4/9] netfilter: h323: eliminate anonymous module_init & module_exit
On 3/17/22 08:49, Pablo Neira Ayuso wrote:
> On Wed, Mar 16, 2022 at 12:20:05PM -0700, Randy Dunlap wrote:
>> Eliminate anonymous module_init() and module_exit(), which can lead to
>> confusion or ambiguity when reading System.map, crashes/oops/bugs,
>> or an initcall_debug log.
>>
>> Give each of these init and exit functions unique driver-specific
>> names to eliminate the anonymous names.
>>
>> Example 1: (System.map)
>> 832fc78c t init
>> 832fc79e t init
>> 832fc8f8 t init
>>
>> Example 2: (initcall_debug log)
>> calling init+0x0/0x12 @ 1
>> initcall init+0x0/0x12 returned 0 after 15 usecs
>> calling init+0x0/0x60 @ 1
>> initcall init+0x0/0x60 returned 0 after 2 usecs
>> calling init+0x0/0x9a @ 1
>> initcall init+0x0/0x9a returned 0 after 74 usecs
>
> LGTM.
>
> Should I route this through the netfilter tree?
Yes, please.
Thanks.
>
>> Fixes: f587de0e2feb ("[NETFILTER]: nf_conntrack/nf_nat: add H.323 helper
>> port")
>> Signed-off-by: Randy Dunlap
>> Cc: Pablo Neira Ayuso
>> Cc: Jozsef Kadlecsik
>> Cc: Florian Westphal
>> Cc: netfilter-de...@vger.kernel.org
>> Cc: coret...@netfilter.org
>> Cc: "David S. Miller"
>> Cc: Jakub Kicinski
>> Cc: net...@vger.kernel.org
>> ---
>> net/ipv4/netfilter/nf_nat_h323.c |8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> --- lnx-517-rc8.orig/net/ipv4/netfilter/nf_nat_h323.c
>> +++ lnx-517-rc8/net/ipv4/netfilter/nf_nat_h323.c
>> @@ -580,7 +580,7 @@ static struct nf_ct_helper_expectfn call
>> };
>>
>>
>> //
>> -static int __init init(void)
>> +static int __init nf_nat_h323_init(void)
>> {
>> BUG_ON(set_h245_addr_hook != NULL);
>> BUG_ON(set_h225_addr_hook != NULL);
>> @@ -607,7 +607,7 @@ static int __init init(void)
>> }
>>
>>
>> //
>> -static void __exit fini(void)
>> +static void __exit nf_nat_h323_fini(void)
>> {
>> RCU_INIT_POINTER(set_h245_addr_hook, NULL);
>> RCU_INIT_POINTER(set_h225_addr_hook, NULL);
>> @@ -624,8 +624,8 @@ static void __exit fini(void)
>> }
>>
>>
>> //
>> -module_init(init);
>> -module_exit(fini);
>> +module_init(nf_nat_h323_init);
>> +module_exit(nf_nat_h323_fini);
>>
>> MODULE_AUTHOR("Jing Min Zhao ");
>> MODULE_DESCRIPTION("H.323 NAT helper");
--
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/9] virtio_console: eliminate anonymous module_init & module_exit
On 3/17/22 08:47, Amit Shah wrote:
> On Wed, 2022-03-16 at 12:20 -0700, Randy Dunlap wrote:
>> Eliminate anonymous module_init() and module_exit(), which can lead to
>> confusion or ambiguity when reading System.map, crashes/oops/bugs,
>> or an initcall_debug log.
>>
>> Give each of these init and exit functions unique driver-specific
>> names to eliminate the anonymous names.
>>
>> Example 1: (System.map)
>> 832fc78c t init
>> 832fc79e t init
>> 832fc8f8 t init
>>
>> Example 2: (initcall_debug log)
>> calling init+0x0/0x12 @ 1
>> initcall init+0x0/0x12 returned 0 after 15 usecs
>> calling init+0x0/0x60 @ 1
>> initcall init+0x0/0x60 returned 0 after 2 usecs
>> calling init+0x0/0x9a @ 1
>> initcall init+0x0/0x9a returned 0 after 74 usecs
>>
>> Fixes: 31610434bc35 ("Virtio console driver")
>> Fixes: 7177876fea83 ("virtio: console: Add ability to remove module")
>> Signed-off-by: Randy Dunlap <
>> rdun...@infradead.org
>>>
>> Cc: Amit Shah <
>> a...@kernel.org
>>>
>> Cc:
>> virtualization@lists.linux-foundation.org
>>
>> Cc: Arnd Bergmann <
>> a...@arndb.de
>>>
>> Cc: Greg Kroah-Hartman <
>> gre...@linuxfoundation.org
>>>
>> ---
>> drivers/char/virtio_console.c |8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> Reviewed-by: Amit Shah
>
> I don't think the Fixes-by really applies here, though - we don't
> really want to push this into stable, nor do we want any automated
> tools to pick this up because of that tag..
Yeah, I'm fine with that.
thanks.
--
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 6/8] drm/shmem-helper: Add generic memory shrinker
On Tue, Mar 15, 2022 at 01:42:51AM +0300, Dmitry Osipenko wrote:
> Introduce a common DRM SHMEM shrinker. It allows to reduce code
> duplication among DRM drivers, it also handles complicated lockings
> for the drivers. This is initial version of the shrinker that covers
> basic needs of GPU drivers.
>
> This patch is based on a couple ideas borrowed from Rob's Clark MSM
> shrinker and Thomas' Zimmermann variant of SHMEM shrinker.
>
> GPU drivers that want to use generic DRM memory shrinker must support
> generic GEM reservations.
>
> Signed-off-by: Daniel Almeida
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 194 +
> include/drm/drm_device.h | 4 +
> include/drm/drm_gem.h | 11 ++
> include/drm/drm_gem_shmem_helper.h | 25
> 4 files changed, 234 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 37009418cd28..35be2ee98f11 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -139,6 +139,9 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> {
> struct drm_gem_object *obj = >base;
>
> + /* take out shmem GEM object from the memory shrinker */
> + drm_gem_shmem_madvise(shmem, 0);
> +
> WARN_ON(shmem->vmap_use_count);
>
> if (obj->import_attach) {
> @@ -163,6 +166,42 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
>
> +static void drm_gem_shmem_update_purgeable_status(struct
> drm_gem_shmem_object *shmem)
> +{
> + struct drm_gem_object *obj = >base;
> + struct drm_gem_shmem_shrinker *gem_shrinker = obj->dev->shmem_shrinker;
> + size_t page_count = obj->size >> PAGE_SHIFT;
> +
> + if (!gem_shrinker || obj->import_attach || !obj->funcs->purge)
> + return;
> +
> + mutex_lock(>vmap_lock);
> + mutex_lock(>pages_lock);
> + mutex_lock(_shrinker->lock);
Uh this is just terrible I think.
Can't we move shmem helpers over to reasonable locking, i.e. per-object
dma_resv_lock for everything? I know it's a pile of work, but I think
we're way past the point with things like this popping up where we should
just bite that bullet.
I discussed the full thing with Daniel Stone, but maybe a joint refresher
on irc would be a good thing.
-Daniel
> +
> + if (shmem->madv < 0) {
> + list_del_init(>madv_list);
> + goto unlock;
> + } else if (shmem->madv > 0) {
> + if (!list_empty(>madv_list))
> + goto unlock;
> +
> + WARN_ON(gem_shrinker->shrinkable_count + page_count <
> page_count);
> + gem_shrinker->shrinkable_count += page_count;
> +
> + list_add_tail(>madv_list, _shrinker->lru);
> + } else if (!list_empty(>madv_list)) {
> + list_del_init(>madv_list);
> +
> + WARN_ON(gem_shrinker->shrinkable_count < page_count);
> + gem_shrinker->shrinkable_count -= page_count;
> + }
> +unlock:
> + mutex_unlock(_shrinker->lock);
> + mutex_unlock(>pages_lock);
> + mutex_unlock(>vmap_lock);
> +}
> +
> static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
> {
> struct drm_gem_object *obj = >base;
> @@ -366,6 +405,8 @@ int drm_gem_shmem_vmap(struct drm_gem_shmem_object *shmem,
> ret = drm_gem_shmem_vmap_locked(shmem, map);
> mutex_unlock(>vmap_lock);
>
> + drm_gem_shmem_update_purgeable_status(shmem);
> +
> return ret;
> }
> EXPORT_SYMBOL(drm_gem_shmem_vmap);
> @@ -409,6 +450,8 @@ void drm_gem_shmem_vunmap(struct drm_gem_shmem_object
> *shmem,
> mutex_lock(>vmap_lock);
> drm_gem_shmem_vunmap_locked(shmem, map);
> mutex_unlock(>vmap_lock);
> +
> + drm_gem_shmem_update_purgeable_status(shmem);
> }
> EXPORT_SYMBOL(drm_gem_shmem_vunmap);
>
> @@ -451,6 +494,8 @@ int drm_gem_shmem_madvise(struct drm_gem_shmem_object
> *shmem, int madv)
>
> mutex_unlock(>pages_lock);
>
> + drm_gem_shmem_update_purgeable_status(shmem);
> +
> return (madv >= 0);
> }
> EXPORT_SYMBOL(drm_gem_shmem_madvise);
> @@ -763,6 +808,155 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device
> *dev,
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
>
> +static struct drm_gem_shmem_shrinker *
> +to_drm_shrinker(struct shrinker *shrinker)
> +{
> + return container_of(shrinker, struct drm_gem_shmem_shrinker, base);
> +}
> +
> +static unsigned long
> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> + struct shrink_control *sc)
> +{
> + struct drm_gem_shmem_shrinker *gem_shrinker = to_drm_shrinker(shrinker);
> + u64 count = gem_shrinker->shrinkable_count;
> +
> + if (count >= SHRINK_EMPTY)
> + return SHRINK_EMPTY - 1;
> +
> + return count ?:
Re: [PATCH v2 6/8] drm/shmem-helper: Add generic memory shrinker
On Wed, Mar 16, 2022 at 5:13 PM Dmitry Osipenko
wrote:
>
> On 3/16/22 23:00, Rob Clark wrote:
> > On Mon, Mar 14, 2022 at 3:44 PM Dmitry Osipenko
> > wrote:
> >>
> >> Introduce a common DRM SHMEM shrinker. It allows to reduce code
> >> duplication among DRM drivers, it also handles complicated lockings
> >> for the drivers. This is initial version of the shrinker that covers
> >> basic needs of GPU drivers.
> >>
> >> This patch is based on a couple ideas borrowed from Rob's Clark MSM
> >> shrinker and Thomas' Zimmermann variant of SHMEM shrinker.
> >>
> >> GPU drivers that want to use generic DRM memory shrinker must support
> >> generic GEM reservations.
> >>
> >> Signed-off-by: Daniel Almeida
> >> Signed-off-by: Dmitry Osipenko
> >> ---
> >> drivers/gpu/drm/drm_gem_shmem_helper.c | 194 +
> >> include/drm/drm_device.h | 4 +
> >> include/drm/drm_gem.h | 11 ++
> >> include/drm/drm_gem_shmem_helper.h | 25
> >> 4 files changed, 234 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> >> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> >> index 37009418cd28..35be2ee98f11 100644
> >> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> >> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> >> @@ -139,6 +139,9 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> >> *shmem)
> >> {
> >> struct drm_gem_object *obj = >base;
> >>
> >> + /* take out shmem GEM object from the memory shrinker */
> >> + drm_gem_shmem_madvise(shmem, 0);
> >> +
> >> WARN_ON(shmem->vmap_use_count);
> >>
> >> if (obj->import_attach) {
> >> @@ -163,6 +166,42 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> >> *shmem)
> >> }
> >> EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
> >>
> >> +static void drm_gem_shmem_update_purgeable_status(struct
> >> drm_gem_shmem_object *shmem)
> >> +{
> >> + struct drm_gem_object *obj = >base;
> >> + struct drm_gem_shmem_shrinker *gem_shrinker =
> >> obj->dev->shmem_shrinker;
> >> + size_t page_count = obj->size >> PAGE_SHIFT;
> >> +
> >> + if (!gem_shrinker || obj->import_attach || !obj->funcs->purge)
> >> + return;
> >> +
> >> + mutex_lock(>vmap_lock);
> >> + mutex_lock(>pages_lock);
> >> + mutex_lock(_shrinker->lock);
> >> +
> >> + if (shmem->madv < 0) {
> >> + list_del_init(>madv_list);
> >> + goto unlock;
> >> + } else if (shmem->madv > 0) {
> >> + if (!list_empty(>madv_list))
> >> + goto unlock;
> >> +
> >> + WARN_ON(gem_shrinker->shrinkable_count + page_count <
> >> page_count);
> >> + gem_shrinker->shrinkable_count += page_count;
> >> +
> >> + list_add_tail(>madv_list, _shrinker->lru);
> >> + } else if (!list_empty(>madv_list)) {
> >> + list_del_init(>madv_list);
> >> +
> >> + WARN_ON(gem_shrinker->shrinkable_count < page_count);
> >> + gem_shrinker->shrinkable_count -= page_count;
> >> + }
> >> +unlock:
> >> + mutex_unlock(_shrinker->lock);
> >> + mutex_unlock(>pages_lock);
> >> + mutex_unlock(>vmap_lock);
> >> +}
> >> +
> >> static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object
> >> *shmem)
> >> {
> >> struct drm_gem_object *obj = >base;
> >> @@ -366,6 +405,8 @@ int drm_gem_shmem_vmap(struct drm_gem_shmem_object
> >> *shmem,
> >> ret = drm_gem_shmem_vmap_locked(shmem, map);
> >> mutex_unlock(>vmap_lock);
> >>
> >> + drm_gem_shmem_update_purgeable_status(shmem);
> >> +
> >> return ret;
> >> }
> >> EXPORT_SYMBOL(drm_gem_shmem_vmap);
> >> @@ -409,6 +450,8 @@ void drm_gem_shmem_vunmap(struct drm_gem_shmem_object
> >> *shmem,
> >> mutex_lock(>vmap_lock);
> >> drm_gem_shmem_vunmap_locked(shmem, map);
> >> mutex_unlock(>vmap_lock);
> >> +
> >> + drm_gem_shmem_update_purgeable_status(shmem);
> >> }
> >> EXPORT_SYMBOL(drm_gem_shmem_vunmap);
> >>
> >> @@ -451,6 +494,8 @@ int drm_gem_shmem_madvise(struct drm_gem_shmem_object
> >> *shmem, int madv)
> >>
> >> mutex_unlock(>pages_lock);
> >>
> >> + drm_gem_shmem_update_purgeable_status(shmem);
> >> +
> >> return (madv >= 0);
> >> }
> >> EXPORT_SYMBOL(drm_gem_shmem_madvise);
> >> @@ -763,6 +808,155 @@ drm_gem_shmem_prime_import_sg_table(struct
> >> drm_device *dev,
> >> }
> >> EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
> >>
> >> +static struct drm_gem_shmem_shrinker *
> >> +to_drm_shrinker(struct shrinker *shrinker)
> >> +{
> >> + return container_of(shrinker, struct drm_gem_shmem_shrinker, base);
> >> +}
> >> +
> >> +static unsigned long
> >> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> >> +struct shrink_control *sc)
> >> +{
> >> + struct drm_gem_shmem_shrinker *gem_shrinker =
> >>
Re: (subset) [PATCH 0/9] treewide: eliminate anonymous module_init & module_exit
On Wed, 16 Mar 2022 12:20:01 -0700, Randy Dunlap wrote: > There are a number of drivers that use "module_init(init)" and > "module_exit(exit)", which are anonymous names and can lead to > confusion or ambiguity when reading System.map, crashes/oops/bugs, > or an initcall_debug log. > > Give each of these init and exit functions unique driver-specific > names to eliminate the anonymous names. > > [...] Applied, thanks! [1/9] virtio_blk: eliminate anonymous module_init & module_exit commit: bcfe9b6cbb4438b8c1cc4bd475221652c8f9301b Best regards, -- Jens Axboe ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/9] virtio_console: eliminate anonymous module_init & module_exit
On Wed, 2022-03-16 at 12:20 -0700, Randy Dunlap wrote:
> Eliminate anonymous module_init() and module_exit(), which can lead to
> confusion or ambiguity when reading System.map, crashes/oops/bugs,
> or an initcall_debug log.
>
> Give each of these init and exit functions unique driver-specific
> names to eliminate the anonymous names.
>
> Example 1: (System.map)
> 832fc78c t init
> 832fc79e t init
> 832fc8f8 t init
>
> Example 2: (initcall_debug log)
> calling init+0x0/0x12 @ 1
> initcall init+0x0/0x12 returned 0 after 15 usecs
> calling init+0x0/0x60 @ 1
> initcall init+0x0/0x60 returned 0 after 2 usecs
> calling init+0x0/0x9a @ 1
> initcall init+0x0/0x9a returned 0 after 74 usecs
>
> Fixes: 31610434bc35 ("Virtio console driver")
> Fixes: 7177876fea83 ("virtio: console: Add ability to remove module")
> Signed-off-by: Randy Dunlap <
> rdun...@infradead.org
> >
> Cc: Amit Shah <
> a...@kernel.org
> >
> Cc:
> virtualization@lists.linux-foundation.org
>
> Cc: Arnd Bergmann <
> a...@arndb.de
> >
> Cc: Greg Kroah-Hartman <
> gre...@linuxfoundation.org
> >
> ---
> drivers/char/virtio_console.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Amit Shah
I don't think the Fixes-by really applies here, though - we don't
really want to push this into stable, nor do we want any automated
tools to pick this up because of that tag..
Amit
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net-next v4 1/2] af_vsock: SOCK_SEQPACKET receive timeout test
On Thu, Mar 17, 2022 at 08:31:49AM +, Krasnov Arseniy Vladimirovich wrote: Test for receive timeout check: connection is established, receiver sets timeout, but sender does nothing. Receiver's 'read()' call must return EAGAIN. Signed-off-by: Krasnov Arseniy Vladimirovich --- v3 -> v4: 1) Fix stupid bug about invalid 'if()' line. tools/testing/vsock/vsock_test.c | 84 1 file changed, 84 insertions(+) Everything is okay now, tests pass and the patch looks good to me: Reviewed-by: Stefano Garzarella Thanks, Stefano ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 5/9] virtio-scsi: eliminate anonymous module_init & module_exit
On Wed, Mar 16, 2022 at 12:20:06PM -0700, Randy Dunlap wrote:
> Eliminate anonymous module_init() and module_exit(), which can lead to
> confusion or ambiguity when reading System.map, crashes/oops/bugs,
> or an initcall_debug log.
>
> Give each of these init and exit functions unique driver-specific
> names to eliminate the anonymous names.
>
> Example 1: (System.map)
> 832fc78c t init
> 832fc79e t init
> 832fc8f8 t init
>
> Example 2: (initcall_debug log)
> calling init+0x0/0x12 @ 1
> initcall init+0x0/0x12 returned 0 after 15 usecs
> calling init+0x0/0x60 @ 1
> initcall init+0x0/0x60 returned 0 after 2 usecs
> calling init+0x0/0x9a @ 1
> initcall init+0x0/0x9a returned 0 after 74 usecs
>
> Fixes: 4fe74b1cb051 ("[SCSI] virtio-scsi: SCSI driver for QEMU based virtual
> machines")
> Signed-off-by: Randy Dunlap
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: Paolo Bonzini
> Cc: Stefan Hajnoczi
> Cc: "James E.J. Bottomley"
> Cc: "Martin K. Petersen"
> Cc: linux-s...@vger.kernel.org
> Cc: virtualization@lists.linux-foundation.org
> ---
> drivers/scsi/virtio_scsi.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> --- lnx-517-rc8.orig/drivers/scsi/virtio_scsi.c
> +++ lnx-517-rc8/drivers/scsi/virtio_scsi.c
> @@ -988,7 +988,7 @@ static struct virtio_driver virtio_scsi_
> .remove = virtscsi_remove,
> };
>
> -static int __init init(void)
> +static int __init virtio_scsi_init(void)
> {
> int ret = -ENOMEM;
>
> @@ -1020,14 +1020,14 @@ error:
> return ret;
> }
>
> -static void __exit fini(void)
> +static void __exit virtio_scsi_fini(void)
> {
> unregister_virtio_driver(_scsi_driver);
> mempool_destroy(virtscsi_cmd_pool);
> kmem_cache_destroy(virtscsi_cmd_cache);
> }
> -module_init(init);
> -module_exit(fini);
> +module_init(virtio_scsi_init);
> +module_exit(virtio_scsi_fini);
>
> MODULE_DEVICE_TABLE(virtio, id_table);
> MODULE_DESCRIPTION("Virtio SCSI HBA driver");
>
Reviewed-by: Stefan Hajnoczi
signature.asc
Description: PGP signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 1/9] virtio_blk: eliminate anonymous module_init & module_exit
On Wed, Mar 16, 2022 at 12:20:02PM -0700, Randy Dunlap wrote:
> Eliminate anonymous module_init() and module_exit(), which can lead to
> confusion or ambiguity when reading System.map, crashes/oops/bugs,
> or an initcall_debug log.
>
> Give each of these init and exit functions unique driver-specific
> names to eliminate the anonymous names.
>
> Example 1: (System.map)
> 832fc78c t init
> 832fc79e t init
> 832fc8f8 t init
>
> Example 2: (initcall_debug log)
> calling init+0x0/0x12 @ 1
> initcall init+0x0/0x12 returned 0 after 15 usecs
> calling init+0x0/0x60 @ 1
> initcall init+0x0/0x60 returned 0 after 2 usecs
> calling init+0x0/0x9a @ 1
> initcall init+0x0/0x9a returned 0 after 74 usecs
>
> Fixes: e467cde23818 ("Block driver using virtio.")
> Signed-off-by: Randy Dunlap
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: Paolo Bonzini
> Cc: Stefan Hajnoczi
> Cc: virtualization@lists.linux-foundation.org
> Cc: Jens Axboe
> Cc: linux-bl...@vger.kernel.org
> ---
> drivers/block/virtio_blk.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> --- lnx-517-rc8.orig/drivers/block/virtio_blk.c
> +++ lnx-517-rc8/drivers/block/virtio_blk.c
> @@ -1058,7 +1058,7 @@ static struct virtio_driver virtio_blk =
> #endif
> };
>
> -static int __init init(void)
> +static int __init virtio_blk_init(void)
> {
> int error;
>
> @@ -1084,14 +1084,14 @@ out_destroy_workqueue:
> return error;
> }
>
> -static void __exit fini(void)
> +static void __exit virtio_blk_fini(void)
> {
> unregister_virtio_driver(_blk);
> unregister_blkdev(major, "virtblk");
> destroy_workqueue(virtblk_wq);
> }
> -module_init(init);
> -module_exit(fini);
> +module_init(virtio_blk_init);
> +module_exit(virtio_blk_fini);
>
> MODULE_DEVICE_TABLE(virtio, id_table);
> MODULE_DESCRIPTION("Virtio block driver");
>
Reviewed-by: Stefan Hajnoczi
signature.asc
Description: PGP signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net-next v3 2/2] af_vsock: SOCK_SEQPACKET broken buffer test
On Thu, Mar 17, 2022 at 05:28:21AM +, Krasnov Arseniy Vladimirovich wrote: Add test where sender sends two message, each with own data pattern. Reader tries to read first to broken buffer: it has three pages size, but middle page is unmapped. Then, reader tries to read second message to valid buffer. Test checks, that uncopied part of first message was dropped and thus not copied as part of second message. Signed-off-by: Krasnov Arseniy Vladimirovich --- v2 -> v3: 1) "got X, expected Y" -> "expected X, got Y". 2) Some checkpatch.pl fixes. tools/testing/vsock/vsock_test.c | 131 +++ 1 file changed, 131 insertions(+) Reviewed-by: Stefano Garzarella ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net-next v3 1/2] af_vsock: SOCK_SEQPACKET receive timeout test
On Thu, Mar 17, 2022 at 05:26:45AM +, Krasnov Arseniy Vladimirovich wrote:
Test for receive timeout check: connection is established,
receiver sets timeout, but sender does nothing. Receiver's
'read()' call must return EAGAIN.
Signed-off-by: Krasnov Arseniy Vladimirovich
---
v2 -> v3:
1) Use 'fprintf()' instead of 'perror()' where 'errno' variable
is not affected.
2) Print 'read()' overhead.
tools/testing/vsock/vsock_test.c | 84
1 file changed, 84 insertions(+)
diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
index 2a3638c0a008..f5498de6751d 100644
--- a/tools/testing/vsock/vsock_test.c
+++ b/tools/testing/vsock/vsock_test.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "timeout.h"
#include "control.h"
@@ -391,6 +392,84 @@ static void test_seqpacket_msg_trunc_server(const struct
test_opts *opts)
close(fd);
}
+static time_t current_nsec(void)
+{
+ struct timespec ts;
+
+ if (clock_gettime(CLOCK_REALTIME, )) {
+ perror("clock_gettime(3) failed");
+ exit(EXIT_FAILURE);
+ }
+
+ return (ts.tv_sec * 10ULL) + ts.tv_nsec;
+}
+
+#define RCVTIMEO_TIMEOUT_SEC 1
+#define READ_OVERHEAD_NSEC 25000 /* 0.25 sec */
+
+static void test_seqpacket_timeout_client(const struct test_opts *opts)
+{
+ int fd;
+ struct timeval tv;
+ char dummy;
+ time_t read_enter_ns;
+ time_t read_overhead_ns;
+
+ fd = vsock_seqpacket_connect(opts->peer_cid, 1234);
+ if (fd < 0) {
+ perror("connect");
+ exit(EXIT_FAILURE);
+ }
+
+ tv.tv_sec = RCVTIMEO_TIMEOUT_SEC;
+ tv.tv_usec = 0;
+
+ if (setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, (void *), sizeof(tv)) ==
-1) {
+ perror("setsockopt 'SO_RCVTIMEO'");
+ exit(EXIT_FAILURE);
+ }
+
+ read_enter_ns = current_nsec();
+
+ if (errno != EAGAIN) {
+ perror("EAGAIN expected");
+ exit(EXIT_FAILURE);
+ }
Should this check go after read()?
Indeed now the test fails on my environment with "EAGAIN expected"
message.
The rest LGTM :-)
Stefano
+
+ if (read(fd, , sizeof(dummy)) != -1) {
+ fprintf(stderr,
+ "expected 'dummy' read(2) failure\n");
+ exit(EXIT_FAILURE);
+ }
+
+ read_overhead_ns = current_nsec() - read_enter_ns -
+ 10ULL * RCVTIMEO_TIMEOUT_SEC;
+
+ if (read_overhead_ns > READ_OVERHEAD_NSEC) {
+ fprintf(stderr,
+ "too much time in read(2), %lu > %i ns\n",
+ read_overhead_ns, READ_OVERHEAD_NSEC);
+ exit(EXIT_FAILURE);
+ }
+
+ control_writeln("WAITDONE");
+ close(fd);
+}
+
+static void test_seqpacket_timeout_server(const struct test_opts *opts)
+{
+ int fd;
+
+ fd = vsock_seqpacket_accept(VMADDR_CID_ANY, 1234, NULL);
+ if (fd < 0) {
+ perror("accept");
+ exit(EXIT_FAILURE);
+ }
+
+ control_expectln("WAITDONE");
+ close(fd);
+}
+
static struct test_case test_cases[] = {
{
.name = "SOCK_STREAM connection reset",
@@ -431,6 +510,11 @@ static struct test_case test_cases[] = {
.run_client = test_seqpacket_msg_trunc_client,
.run_server = test_seqpacket_msg_trunc_server,
},
+ {
+ .name = "SOCK_SEQPACKET timeout",
+ .run_client = test_seqpacket_timeout_client,
+ .run_server = test_seqpacket_timeout_server,
+ },
{},
};
--
2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 6/9] usb: gadget: eliminate anonymous module_init & module_exit
On 3/16/22 20:29, Ira Weiny wrote:
> On Wed, Mar 16, 2022 at 12:20:07PM -0700, Randy Dunlap wrote:
>> Eliminate anonymous module_init() and module_exit(), which can lead to
>> confusion or ambiguity when reading System.map, crashes/oops/bugs,
>> or an initcall_debug log.
>>
>> Give each of these init and exit functions unique driver-specific
>> names to eliminate the anonymous names.
>>
>> Example 1: (System.map)
>> 832fc78c t init
>> 832fc79e t init
>> 832fc8f8 t init
>>
>> Example 2: (initcall_debug log)
>> calling init+0x0/0x12 @ 1
>> initcall init+0x0/0x12 returned 0 after 15 usecs
>> calling init+0x0/0x60 @ 1
>> initcall init+0x0/0x60 returned 0 after 2 usecs
>> calling init+0x0/0x9a @ 1
>> initcall init+0x0/0x9a returned 0 after 74 usecs
>>
>> Fixes: bd25a14edb75 ("usb: gadget: legacy/serial: allow dynamic removal")
>> Fixes: 7bb5ea54be47 ("usb gadget serial: use composite gadget framework")
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>
> I continue to be confused about the latest rules for the Fixes tag but this
> one
> in particular seems completely useless. This is the 'beginning of time'
> commit
> by Linus AFAICT. So do any of these Fixes tags need to be in this series?
I guess it mostly depends on whether they get applied to stable trees, but
it's entirely fine with me if they don't.
{I also corrected Felipe's email address here.}
> Regardless:
>
> Reviewed-by: Ira Weiny
Thanks.
>
>> Signed-off-by: Randy Dunlap
>> Cc: Felipe Balbi
>> Cc: Michał Mirosław
>> Cc: Greg Kroah-Hartman
>> Cc: Sebastian Andrzej Siewior
>> Cc: linux-...@vger.kernel.org
>> ---
>> drivers/usb/gadget/legacy/inode.c |8
>> drivers/usb/gadget/legacy/serial.c | 10 +-
>> drivers/usb/gadget/udc/dummy_hcd.c |8
>> 3 files changed, 13 insertions(+), 13 deletions(-)
>>
>> --- lnx-517-rc8.orig/drivers/usb/gadget/legacy/serial.c
>> +++ lnx-517-rc8/drivers/usb/gadget/legacy/serial.c
>> @@ -273,7 +273,7 @@ static struct usb_composite_driver gseri
>> static int switch_gserial_enable(bool do_enable)
>> {
>> if (!serial_config_driver.label)
>> -/* init() was not called, yet */
>> +/* gserial_init() was not called, yet */
>> return 0;
>>
>> if (do_enable)
>> @@ -283,7 +283,7 @@ static int switch_gserial_enable(bool do
>> return 0;
>> }
>>
>> -static int __init init(void)
>> +static int __init gserial_init(void)
>> {
>> /* We *could* export two configs; that'd be much cleaner...
>> * but neither of these product IDs was defined that way.
>> @@ -314,11 +314,11 @@ static int __init init(void)
>>
>> return usb_composite_probe(_driver);
>> }
>> -module_init(init);
>> +module_init(gserial_init);
>>
>> -static void __exit cleanup(void)
>> +static void __exit gserial_cleanup(void)
>> {
>> if (enable)
>> usb_composite_unregister(_driver);
>> }
>> -module_exit(cleanup);
>> +module_exit(gserial_cleanup);
>> --- lnx-517-rc8.orig/drivers/usb/gadget/udc/dummy_hcd.c
>> +++ lnx-517-rc8/drivers/usb/gadget/udc/dummy_hcd.c
>> @@ -2765,7 +2765,7 @@ static struct platform_driver dummy_hcd_
>> static struct platform_device *the_udc_pdev[MAX_NUM_UDC];
>> static struct platform_device *the_hcd_pdev[MAX_NUM_UDC];
>>
>> -static int __init init(void)
>> +static int __init dummy_hcd_init(void)
>> {
>> int retval = -ENOMEM;
>> int i;
>> @@ -2887,9 +2887,9 @@ err_alloc_udc:
>> platform_device_put(the_hcd_pdev[i]);
>> return retval;
>> }
>> -module_init(init);
>> +module_init(dummy_hcd_init);
>>
>> -static void __exit cleanup(void)
>> +static void __exit dummy_hcd_cleanup(void)
>> {
>> int i;
>>
>> @@ -2905,4 +2905,4 @@ static void __exit cleanup(void)
>> platform_driver_unregister(_udc_driver);
>> platform_driver_unregister(_hcd_driver);
>> }
>> -module_exit(cleanup);
>> +module_exit(dummy_hcd_cleanup);
>> --- lnx-517-rc8.orig/drivers/usb/gadget/legacy/inode.c
>> +++ lnx-517-rc8/drivers/usb/gadget/legacy/inode.c
>> @@ -2101,7 +2101,7 @@ MODULE_ALIAS_FS("gadgetfs");
>>
>> /*--*/
>>
>> -static int __init init (void)
>> +static int __init gadgetfs_init (void)
>> {
>> int status;
>>
>> @@ -2111,12 +2111,12 @@ static int __init init (void)
>> shortname, driver_desc);
>> return status;
>> }
>> -module_init (init);
>> +module_init (gadgetfs_init);
>>
>> -static void __exit cleanup (void)
>> +static void __exit gadgetfs_cleanup (void)
>> {
>> pr_debug ("unregister %s\n", shortname);
>> unregister_filesystem (_type);
>> }
>> -module_exit (cleanup);
>> +module_exit (gadgetfs_cleanup);
>>
--
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
