* [PATCH net] hv_netvsc: Fix extra rcu_read_unlock in netvsc_recv_callback()
From: Haiyang Zhang @ 2019-07-19 17:33 UTC (permalink / raw)
To: sashal@kernel.org, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org
Cc: Haiyang Zhang, KY Srinivasan, Stephen Hemminger, olaf@aepfle.de,
vkuznets, davem@davemloft.net, linux-kernel@vger.kernel.org
There is an extra rcu_read_unlock left in netvsc_recv_callback(),
after a previous patch that removes RCU from this function.
This patch removes the extra RCU unlock.
Fixes: 345ac08990b8 ("hv_netvsc: pass netvsc_device to receive callback")
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/net/hyperv/netvsc_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index afdcc56..3544e19 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -836,7 +836,6 @@ int netvsc_recv_callback(struct net_device *net,
if (unlikely(!skb)) {
++net_device_ctx->eth_stats.rx_no_memory;
- rcu_read_unlock();
return NVSP_STAT_FAIL;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 0/9] x86: Concurrent TLB flushes
From: Dave Hansen @ 2019-07-19 21:36 UTC (permalink / raw)
To: Nadav Amit, Andy Lutomirski, Dave Hansen
Cc: x86, linux-kernel, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Boris Ostrovsky, Haiyang Zhang, Josh Poimboeuf,
Juergen Gross, K. Y. Srinivasan, Paolo Bonzini, Rik van Riel,
Sasha Levin, Stephen Hemminger, kvm, linux-hyperv, virtualization,
xen-devel
In-Reply-To: <20190719005837.4150-1-namit@vmware.com>
Thanks for doing this, it's something I've been hoping someone would do
for a long time.
While I kinda wish we had performance data for each individual patch (at
least the behavior-changing ones), this does look like a good
improvement. That might, for instance, tell is a bit about how the
separating out "is_lazy" compares to the "check before setting"
optimization. But, they're both sane enough on their own that I'm not
too worried.
I had some nits that I hope get covered in later revisions, if sent.
But, overall looks fine. For the series:
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
^ permalink raw reply
* Re: [PATCH net] hv_netvsc: Fix extra rcu_read_unlock in netvsc_recv_callback()
From: David Miller @ 2019-07-22 3:41 UTC (permalink / raw)
To: haiyangz
Cc: sashal, linux-hyperv, netdev, kys, sthemmin, olaf, vkuznets,
linux-kernel
In-Reply-To: <1563557581-17669-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Fri, 19 Jul 2019 17:33:51 +0000
> There is an extra rcu_read_unlock left in netvsc_recv_callback(),
> after a previous patch that removes RCU from this function.
> This patch removes the extra RCU unlock.
>
> Fixes: 345ac08990b8 ("hv_netvsc: pass netvsc_device to receive callback")
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH 2/8] scsi: take the DMA max mapping size into account
From: Ming Lei @ 2019-07-22 6:00 UTC (permalink / raw)
To: Bart Van Assche
Cc: Christoph Hellwig, Martin K . Petersen, Sagi Grimberg,
Max Gurtovoy, linux-rdma, Linux SCSI List, megaraidlinux.pdl,
MPT-FusionLinux.pdl, linux-hyperv, Linux Kernel Mailing List
In-Reply-To: <5d143a03-edd5-5878-780b-45d87313a813@acm.org>
On Tue, Jun 18, 2019 at 4:57 AM Bart Van Assche <bvanassche@acm.org> wrote:
>
> On 6/17/19 5:19 AM, Christoph Hellwig wrote:
> > We need to limit the devices max_sectors to what the DMA mapping
> > implementation can support. If not we risk running out of swiotlb
> > buffers easily.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > drivers/scsi/scsi_lib.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > index d333bb6b1c59..f233bfd84cd7 100644
> > --- a/drivers/scsi/scsi_lib.c
> > +++ b/drivers/scsi/scsi_lib.c
> > @@ -1768,6 +1768,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
> > blk_queue_max_integrity_segments(q, shost->sg_prot_tablesize);
> > }
> >
> > + shost->max_sectors = min_t(unsigned int, shost->max_sectors,
> > + dma_max_mapping_size(dev) << SECTOR_SHIFT);
> > blk_queue_max_hw_sectors(q, shost->max_sectors);
> > if (shost->unchecked_isa_dma)
> > blk_queue_bounce_limit(q, BLK_BOUNCE_ISA);
>
> Does dma_max_mapping_size() return a value in bytes? Is
> shost->max_sectors a number of sectors? If so, are you sure that "<<
> SECTOR_SHIFT" is the proper conversion? Shouldn't that be ">>
> SECTOR_SHIFT" instead?
Now the patch has been committed, '<< SECTOR_SHIFT' needs to be fixed.
Also the following kernel oops is triggered on qemu, and looks
device->dma_mask is NULL.
[ 5.826483] scsi host0: Virtio SCSI HBA
[ 5.829302] st: Version 20160209, fixed bufsize 32768, s/g segs 256
[ 5.831042] SCSI Media Changer driver v0.25
[ 5.832491] ==================================================================
[ 5.833332] BUG: KASAN: null-ptr-deref in
dma_direct_max_mapping_size+0x30/0x94
[ 5.833332] Read of size 8 at addr 0000000000000000 by task kworker/u17:0/7
[ 5.835506] nvme nvme0: pci function 0000:00:07.0
[ 5.833332]
[ 5.833332] CPU: 2 PID: 7 Comm: kworker/u17:0 Not tainted 5.3.0-rc1 #1328
[ 5.836999] ahci 0000:00:1f.2: version 3.0
[ 5.833332] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS ?-20180724_192412-buildhw-07.phx4
[ 5.833332] Workqueue: events_unbound async_run_entry_fn
[ 5.833332] Call Trace:
[ 5.833332] dump_stack+0x6f/0x9d
[ 5.833332] ? dma_direct_max_mapping_size+0x30/0x94
[ 5.833332] __kasan_report+0x161/0x189
[ 5.833332] ? dma_direct_max_mapping_size+0x30/0x94
[ 5.833332] kasan_report+0xe/0x12
[ 5.833332] dma_direct_max_mapping_size+0x30/0x94
[ 5.833332] __scsi_init_queue+0xd8/0x1f3
[ 5.833332] scsi_mq_alloc_queue+0x62/0x89
[ 5.833332] scsi_alloc_sdev+0x38c/0x479
[ 5.833332] scsi_probe_and_add_lun+0x22d/0x1093
[ 5.833332] ? kobject_set_name_vargs+0xa4/0xb2
[ 5.833332] ? mutex_lock+0x88/0xc4
[ 5.833332] ? scsi_free_host_dev+0x4a/0x4a
[ 5.833332] ? _raw_spin_lock_irqsave+0x8c/0xde
[ 5.833332] ? _raw_write_unlock_irqrestore+0x23/0x23
[ 5.833332] ? ata_tdev_match+0x22/0x45
[ 5.833332] ? attribute_container_add_device+0x160/0x17e
[ 5.833332] ? rpm_resume+0x26a/0x7c0
[ 5.833332] ? kobject_get+0x12/0x43
[ 5.833332] ? rpm_put_suppliers+0x7e/0x7e
[ 5.833332] ? _raw_spin_lock_irqsave+0x8c/0xde
[ 5.833332] ? _raw_write_unlock_irqrestore+0x23/0x23
[ 5.833332] ? scsi_target_destroy+0x135/0x135
[ 5.833332] __scsi_scan_target+0x14b/0x6aa
[ 5.833332] ? pvclock_clocksource_read+0xc0/0x14e
[ 5.833332] ? scsi_add_device+0x20/0x20
[ 5.833332] ? rpm_resume+0x1ae/0x7c0
[ 5.833332] ? rpm_put_suppliers+0x7e/0x7e
[ 5.833332] ? _raw_spin_lock_irqsave+0x8c/0xde
[ 5.833332] ? _raw_write_unlock_irqrestore+0x23/0x23
[ 5.833332] ? pick_next_task_fair+0x976/0xa3d
[ 5.833332] ? mutex_lock+0x88/0xc4
[ 5.833332] scsi_scan_channel+0x76/0x9e
[ 5.833332] scsi_scan_host_selected+0x131/0x176
[ 5.833332] ? scsi_scan_host+0x241/0x241
[ 5.833332] do_scan_async+0x27/0x219
[ 5.833332] ? scsi_scan_host+0x241/0x241
[ 5.833332] async_run_entry_fn+0xdc/0x23d
[ 5.833332] process_one_work+0x327/0x539
[ 5.833332] worker_thread+0x330/0x492
[ 5.833332] ? rescuer_thread+0x41f/0x41f
[ 5.833332] kthread+0x1c6/0x1d5
[ 5.833332] ? kthread_park+0xd3/0xd3
[ 5.833332] ret_from_fork+0x1f/0x30
[ 5.833332] ==================================================================
Thanks,
Ming Lei
^ permalink raw reply
* Re: [PATCH 2/8] scsi: take the DMA max mapping size into account
From: Dexuan-Linux Cui @ 2019-07-22 6:18 UTC (permalink / raw)
To: Ming Lei
Cc: Bart Van Assche, Christoph Hellwig, Martin K . Petersen,
Sagi Grimberg, Max Gurtovoy, linux-rdma, Linux SCSI List,
megaraidlinux.pdl, MPT-FusionLinux.pdl, linux-hyperv,
Linux Kernel Mailing List, Dexuan Cui, v-lide
In-Reply-To: <CACVXFVMWM3xg6EEyoyNjkLPv=8+wQKiHj6erMS_gGX25f-Ot4g@mail.gmail.com>
On Sun, Jul 21, 2019 at 11:01 PM Ming Lei <tom.leiming@gmail.com> wrote:
>
> On Tue, Jun 18, 2019 at 4:57 AM Bart Van Assche <bvanassche@acm.org> wrote:
> >
> > On 6/17/19 5:19 AM, Christoph Hellwig wrote:
> > > We need to limit the devices max_sectors to what the DMA mapping
> > > implementation can support. If not we risk running out of swiotlb
> > > buffers easily.
> > >
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > ---
> > > drivers/scsi/scsi_lib.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > > index d333bb6b1c59..f233bfd84cd7 100644
> > > --- a/drivers/scsi/scsi_lib.c
> > > +++ b/drivers/scsi/scsi_lib.c
> > > @@ -1768,6 +1768,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
> > > blk_queue_max_integrity_segments(q, shost->sg_prot_tablesize);
> > > }
> > >
> > > + shost->max_sectors = min_t(unsigned int, shost->max_sectors,
> > > + dma_max_mapping_size(dev) << SECTOR_SHIFT);
> > > blk_queue_max_hw_sectors(q, shost->max_sectors);
> > > if (shost->unchecked_isa_dma)
> > > blk_queue_bounce_limit(q, BLK_BOUNCE_ISA);
> >
> > Does dma_max_mapping_size() return a value in bytes? Is
> > shost->max_sectors a number of sectors? If so, are you sure that "<<
> > SECTOR_SHIFT" is the proper conversion? Shouldn't that be ">>
> > SECTOR_SHIFT" instead?
>
> Now the patch has been committed, '<< SECTOR_SHIFT' needs to be fixed.
>
> Also the following kernel oops is triggered on qemu, and looks
> device->dma_mask is NULL.
>
> Ming Lei
FYI: we also see the panic with a Linux kernel 5.2.0-next-20190719
running on Hyper-V:
[ 7.429053] RIP: 0010:dma_direct_max_mapping_size+0x26/0x80
[ 7.429053] Code: 0f b6 c0 c3 0f 1f 44 00 00 55 48 89 e5 41 54 53
48 89 fb e8 4c 14 00 00 84 c0 74 45 48 8b 83 28 02 00 00 4c 8b a3 38
02 00 00 <48> 8b 00 48 85 c0 74 0c 4d 85 e4 74 36 49 39 c4 4c 0f 47 e0
48 89
[ 7.429053] RSP: 0018:ffffc1d5005efbc0 EFLAGS: 00010202
[ 7.429053] RAX: 0000000000000000 RBX: ffff9cf86d24c428 RCX: 0000000000000000
[ 7.429053] RDX: ffff9cf86d12dd00 RSI: 0000000000000200 RDI: ffff9cf86d24c428
[ 7.429053] RBP: ffffc1d5005efbd0 R08: ffff9cf86fcaf0e0 R09: ffff9cf86e0072c0
[ 7.429053] R10: ffffc1d5005efa70 R11: 00000000000301a0 R12: 0000000000000000
[ 7.429053] R13: ffff9cf86d24c428 R14: 0000000000000400 R15: ffff9cf825cff000
[ 7.429053] FS: 0000000000000000(0000) GS:ffff9cf86fc80000(0000)
knlGS:0000000000000000
[ 7.429053] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7.429053] CR2: 0000000000000000 CR3: 00000003c700a001 CR4: 00000000003606e0
[ 7.456569] NET: Registered protocol family 17
[ 7.429053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 7.469803] Key type dns_resolver registered
[ 7.429053] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 7.429053] Call Trace:
[ 7.429053] dma_max_mapping_size+0x39/0x50
[ 7.429053] __scsi_init_queue+0x7f/0x140
[ 7.429053] scsi_mq_alloc_queue+0x38/0x60
[ 7.429053] scsi_alloc_sdev+0x1da/0x2b0
[ 7.429053] scsi_probe_and_add_lun+0x471/0xe60
[ 7.429053] __scsi_scan_target+0xfc/0x610
[ 7.429053] scsi_scan_channel+0x66/0xa0
[ 7.429053] scsi_scan_host_selected+0xf3/0x160
[ 7.429053] do_scsi_scan_host+0x93/0xa0
[ 7.429053] do_scan_async+0x1c/0x190
[ 7.429053] async_run_entry_fn+0x3c/0x150
[ 7.429053] process_one_work+0x1f7/0x3f0
[ 7.429053] worker_thread+0x34/0x400
[ 7.429053] kthread+0x121/0x140
[ 7.429053] ret_from_fork+0x35/0x40
[ 7.429053] Modules linked in:
[ 7.429053] CR2: 0000000000000000
[ 7.766122] BUG: kernel NULL pointer dereference, address: 0000000000000000
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [PATCH 2/8] scsi: take the DMA max mapping size into account
From: Damien Le Moal @ 2019-07-22 7:40 UTC (permalink / raw)
To: Ming Lei, Bart van Assche
Cc: Christoph Hellwig, Martin K . Petersen, Sagi Grimberg,
Max Gurtovoy, linux-rdma, Linux SCSI List,
megaraidlinux.pdl@broadcom.com, MPT-FusionLinux.pdl@broadcom.com,
linux-hyperv@vger.kernel.org, Linux Kernel Mailing List
In-Reply-To: <CACVXFVMWM3xg6EEyoyNjkLPv=8+wQKiHj6erMS_gGX25f-Ot4g@mail.gmail.com>
On 2019/07/22 15:01, Ming Lei wrote:
> On Tue, Jun 18, 2019 at 4:57 AM Bart Van Assche <bvanassche@acm.org> wrote:
>>
>> On 6/17/19 5:19 AM, Christoph Hellwig wrote:
>>> We need to limit the devices max_sectors to what the DMA mapping
>>> implementation can support. If not we risk running out of swiotlb
>>> buffers easily.
>>>
>>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>>> ---
>>> drivers/scsi/scsi_lib.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>> index d333bb6b1c59..f233bfd84cd7 100644
>>> --- a/drivers/scsi/scsi_lib.c
>>> +++ b/drivers/scsi/scsi_lib.c
>>> @@ -1768,6 +1768,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
>>> blk_queue_max_integrity_segments(q, shost->sg_prot_tablesize);
>>> }
>>>
>>> + shost->max_sectors = min_t(unsigned int, shost->max_sectors,
>>> + dma_max_mapping_size(dev) << SECTOR_SHIFT);
>>> blk_queue_max_hw_sectors(q, shost->max_sectors);
>>> if (shost->unchecked_isa_dma)
>>> blk_queue_bounce_limit(q, BLK_BOUNCE_ISA);
>>
>> Does dma_max_mapping_size() return a value in bytes? Is
>> shost->max_sectors a number of sectors? If so, are you sure that "<<
>> SECTOR_SHIFT" is the proper conversion? Shouldn't that be ">>
>> SECTOR_SHIFT" instead?
>
> Now the patch has been committed, '<< SECTOR_SHIFT' needs to be fixed.
>
> Also the following kernel oops is triggered on qemu, and looks
> device->dma_mask is NULL.
Just hit the exact same problem using tcmu-runner (ZBC file handler) on bare
metal (no QEMU). dev->dma_mask is NULL. No problem with real disks though.
>
> [ 5.826483] scsi host0: Virtio SCSI HBA
> [ 5.829302] st: Version 20160209, fixed bufsize 32768, s/g segs 256
> [ 5.831042] SCSI Media Changer driver v0.25
> [ 5.832491] ==================================================================
> [ 5.833332] BUG: KASAN: null-ptr-deref in
> dma_direct_max_mapping_size+0x30/0x94
> [ 5.833332] Read of size 8 at addr 0000000000000000 by task kworker/u17:0/7
> [ 5.835506] nvme nvme0: pci function 0000:00:07.0
> [ 5.833332]
> [ 5.833332] CPU: 2 PID: 7 Comm: kworker/u17:0 Not tainted 5.3.0-rc1 #1328
> [ 5.836999] ahci 0000:00:1f.2: version 3.0
> [ 5.833332] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
> BIOS ?-20180724_192412-buildhw-07.phx4
> [ 5.833332] Workqueue: events_unbound async_run_entry_fn
> [ 5.833332] Call Trace:
> [ 5.833332] dump_stack+0x6f/0x9d
> [ 5.833332] ? dma_direct_max_mapping_size+0x30/0x94
> [ 5.833332] __kasan_report+0x161/0x189
> [ 5.833332] ? dma_direct_max_mapping_size+0x30/0x94
> [ 5.833332] kasan_report+0xe/0x12
> [ 5.833332] dma_direct_max_mapping_size+0x30/0x94
> [ 5.833332] __scsi_init_queue+0xd8/0x1f3
> [ 5.833332] scsi_mq_alloc_queue+0x62/0x89
> [ 5.833332] scsi_alloc_sdev+0x38c/0x479
> [ 5.833332] scsi_probe_and_add_lun+0x22d/0x1093
> [ 5.833332] ? kobject_set_name_vargs+0xa4/0xb2
> [ 5.833332] ? mutex_lock+0x88/0xc4
> [ 5.833332] ? scsi_free_host_dev+0x4a/0x4a
> [ 5.833332] ? _raw_spin_lock_irqsave+0x8c/0xde
> [ 5.833332] ? _raw_write_unlock_irqrestore+0x23/0x23
> [ 5.833332] ? ata_tdev_match+0x22/0x45
> [ 5.833332] ? attribute_container_add_device+0x160/0x17e
> [ 5.833332] ? rpm_resume+0x26a/0x7c0
> [ 5.833332] ? kobject_get+0x12/0x43
> [ 5.833332] ? rpm_put_suppliers+0x7e/0x7e
> [ 5.833332] ? _raw_spin_lock_irqsave+0x8c/0xde
> [ 5.833332] ? _raw_write_unlock_irqrestore+0x23/0x23
> [ 5.833332] ? scsi_target_destroy+0x135/0x135
> [ 5.833332] __scsi_scan_target+0x14b/0x6aa
> [ 5.833332] ? pvclock_clocksource_read+0xc0/0x14e
> [ 5.833332] ? scsi_add_device+0x20/0x20
> [ 5.833332] ? rpm_resume+0x1ae/0x7c0
> [ 5.833332] ? rpm_put_suppliers+0x7e/0x7e
> [ 5.833332] ? _raw_spin_lock_irqsave+0x8c/0xde
> [ 5.833332] ? _raw_write_unlock_irqrestore+0x23/0x23
> [ 5.833332] ? pick_next_task_fair+0x976/0xa3d
> [ 5.833332] ? mutex_lock+0x88/0xc4
> [ 5.833332] scsi_scan_channel+0x76/0x9e
> [ 5.833332] scsi_scan_host_selected+0x131/0x176
> [ 5.833332] ? scsi_scan_host+0x241/0x241
> [ 5.833332] do_scan_async+0x27/0x219
> [ 5.833332] ? scsi_scan_host+0x241/0x241
> [ 5.833332] async_run_entry_fn+0xdc/0x23d
> [ 5.833332] process_one_work+0x327/0x539
> [ 5.833332] worker_thread+0x330/0x492
> [ 5.833332] ? rescuer_thread+0x41f/0x41f
> [ 5.833332] kthread+0x1c6/0x1d5
> [ 5.833332] ? kthread_park+0xd3/0xd3
> [ 5.833332] ret_from_fork+0x1f/0x30
> [ 5.833332] ==================================================================
>
>
>
> Thanks,
> Ming Lei
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply
* Re: [PATCH v4 3/5] hv: vmbus: Replace page definition with Hyper-V specific one
From: Thomas Gleixner @ 2019-07-22 9:08 UTC (permalink / raw)
To: Sasha Levin
Cc: Maya Nakamura, mikelley, kys, haiyangz, sthemmin, x86,
linux-hyperv, linux-kernel
In-Reply-To: <20190718022228.GF3079@sasha-vm>
On Wed, 17 Jul 2019, Sasha Levin wrote:
> On Fri, Jul 12, 2019 at 08:25:18AM +0000, Maya Nakamura wrote:
> > Replace PAGE_SIZE with HV_HYP_PAGE_SIZE because the guest page size may
> > not be 4096 on all architectures and Hyper-V always runs with a page
> > size of 4096.
> >
> > Signed-off-by: Maya Nakamura <m.maya.nakamura@gmail.com>
> > Reviewed-by: Michael Kelley <mikelley@microsoft.com>
> > Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>
> Thomas, if you're taking this series, could you grab this patch as well
> please (dependencies)?
>
> Acked-by: Sasha Levin <sashal@kernel.org>
Picked it up. The three commits are in
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/hyperv
If you have patches dependend on those either send them my way or pull the
branch into your hyper-v tree.
Thanks,
tglx
^ permalink raw reply
* [PATCH] hv: Use the correct style for SPDX License Identifier
From: Nishad Kamdar @ 2019-07-22 13:31 UTC (permalink / raw)
To: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger
Cc: Sasha Levin, Greg Kroah-Hartman, Joe Perches,
Uwe Kleine-König, linux-hyperv, linux-kernel
This patch corrects the SPDX License Identifier style
in the trace header file related to Microsoft Hyper-V
client drivers.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)
Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
---
drivers/hv/hv_trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/hv_trace.h b/drivers/hv/hv_trace.h
index 999f80a63bff..e70783e33680 100644
--- a/drivers/hv/hv_trace.h
+++ b/drivers/hv/hv_trace.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+/* SPDX-License-Identifier: GPL-2.0 */
#undef TRACE_SYSTEM
#define TRACE_SYSTEM hyperv
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] hv: Use the correct style for SPDX License Identifier
From: Greg Kroah-Hartman @ 2019-07-22 14:08 UTC (permalink / raw)
To: Nishad Kamdar
Cc: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
Joe Perches, Uwe Kleine-König, linux-hyperv, linux-kernel
In-Reply-To: <20190722133112.GA7990@nishad>
On Mon, Jul 22, 2019 at 07:01:17PM +0530, Nishad Kamdar wrote:
> This patch corrects the SPDX License Identifier style
> in the trace header file related to Microsoft Hyper-V
> client drivers.
> For C header files Documentation/process/license-rules.rst
> mandates C-like comments (opposed to C source files where
> C++ style should be used)
>
> Changes made by using a script provided by Joe Perches here:
> https://lkml.org/lkml/2019/2/7/46
>
> Suggested-by: Joe Perches <joe@perches.com>
> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v3 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
From: Peter Zijlstra @ 2019-07-22 19:14 UTC (permalink / raw)
To: Nadav Amit
Cc: Andy Lutomirski, Dave Hansen, x86, linux-kernel, Thomas Gleixner,
Ingo Molnar, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Sasha Levin, Borislav Petkov, Juergen Gross, Paolo Bonzini,
Boris Ostrovsky, linux-hyperv, virtualization, kvm, xen-devel
In-Reply-To: <20190719005837.4150-5-namit@vmware.com>
On Thu, Jul 18, 2019 at 05:58:32PM -0700, Nadav Amit wrote:
> @@ -709,8 +716,9 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
> * doing a speculative memory access.
> */
> if (info->freed_tables) {
> - smp_call_function_many(cpumask, flush_tlb_func_remote,
> - (void *)info, 1);
> + __smp_call_function_many(cpumask, flush_tlb_func_remote,
> + flush_tlb_func_local,
> + (void *)info, 1);
> } else {
> /*
> * Although we could have used on_each_cpu_cond_mask(),
> @@ -737,7 +745,8 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
> if (tlb_is_not_lazy(cpu))
> __cpumask_set_cpu(cpu, cond_cpumask);
> }
> - smp_call_function_many(cond_cpumask, flush_tlb_func_remote,
> + __smp_call_function_many(cond_cpumask, flush_tlb_func_remote,
> + flush_tlb_func_local,
> (void *)info, 1);
> }
> }
Do we really need that _local/_remote distinction? ISTR you had a patch
that frobbed flush_tlb_info into the csd and that gave space
constraints, but I'm not seeing that here (probably a wise, get stuff
merged etc..).
struct __call_single_data {
struct llist_node llist; /* 0 8 */
smp_call_func_t func; /* 8 8 */
void * info; /* 16 8 */
unsigned int flags; /* 24 4 */
/* size: 32, cachelines: 1, members: 4 */
/* padding: 4 */
/* last cacheline: 32 bytes */
};
struct flush_tlb_info {
struct mm_struct * mm; /* 0 8 */
long unsigned int start; /* 8 8 */
long unsigned int end; /* 16 8 */
u64 new_tlb_gen; /* 24 8 */
unsigned int stride_shift; /* 32 4 */
bool freed_tables; /* 36 1 */
/* size: 40, cachelines: 1, members: 6 */
/* padding: 3 */
/* last cacheline: 40 bytes */
};
IIRC what you did was make void *__call_single_data::info the last
member and a union until the full cacheline size (64). Given the above
that would get us 24 bytes for csd, leaving us 40 for that
flush_tlb_info.
But then we can still do something like the below, which doesn't change
things and still gets rid of that dual function crud, simplifying
smp_call_function_many again.
Index: linux-2.6/arch/x86/include/asm/tlbflush.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/tlbflush.h
+++ linux-2.6/arch/x86/include/asm/tlbflush.h
@@ -546,8 +546,9 @@ struct flush_tlb_info {
unsigned long start;
unsigned long end;
u64 new_tlb_gen;
- unsigned int stride_shift;
- bool freed_tables;
+ unsigned int cpu;
+ unsigned short stride_shift;
+ unsigned char freed_tables;
};
#define local_flush_tlb() __flush_tlb()
Index: linux-2.6/arch/x86/mm/tlb.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/tlb.c
+++ linux-2.6/arch/x86/mm/tlb.c
@@ -659,6 +659,27 @@ static void flush_tlb_func_remote(void *
flush_tlb_func_common(f, false, TLB_REMOTE_SHOOTDOWN);
}
+static void flush_tlb_func(void *info)
+{
+ const struct flush_tlb_info *f = info;
+ enum tlb_flush_reason reason = TLB_REMOTE_SHOOTDOWN;
+ bool local = false;
+
+ if (f->cpu == smp_processor_id()) {
+ local = true;
+ reason = (f->mm == NULL) ? TLB_LOCAL_SHOOTDOWN : TLB_LOCAL_MM_SHOOTDOWN;
+ } else {
+ inc_irq_stat(irq_tlb_count);
+
+ if (f->mm && f->mm != this_cpu_read(cpu_tlbstate.loaded_mm))
+ return;
+
+ count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
+ }
+
+ flush_tlb_func_common(f, local, reason);
+}
+
static bool tlb_is_not_lazy(int cpu)
{
return !per_cpu(cpu_tlbstate_shared.is_lazy, cpu);
^ permalink raw reply
* Re: [PATCH v3 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
From: Nadav Amit @ 2019-07-22 19:27 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Andy Lutomirski, Dave Hansen, the arch/x86 maintainers, LKML,
Thomas Gleixner, Ingo Molnar, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, Sasha Levin, Borislav Petkov, Juergen Gross,
Paolo Bonzini, Boris Ostrovsky, linux-hyperv@vger.kernel.org,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
xen-devel@lists.xenproject.org
In-Reply-To: <20190722191433.GD6698@worktop.programming.kicks-ass.net>
> On Jul 22, 2019, at 12:14 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Thu, Jul 18, 2019 at 05:58:32PM -0700, Nadav Amit wrote:
>> @@ -709,8 +716,9 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
>> * doing a speculative memory access.
>> */
>> if (info->freed_tables) {
>> - smp_call_function_many(cpumask, flush_tlb_func_remote,
>> - (void *)info, 1);
>> + __smp_call_function_many(cpumask, flush_tlb_func_remote,
>> + flush_tlb_func_local,
>> + (void *)info, 1);
>> } else {
>> /*
>> * Although we could have used on_each_cpu_cond_mask(),
>> @@ -737,7 +745,8 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
>> if (tlb_is_not_lazy(cpu))
>> __cpumask_set_cpu(cpu, cond_cpumask);
>> }
>> - smp_call_function_many(cond_cpumask, flush_tlb_func_remote,
>> + __smp_call_function_many(cond_cpumask, flush_tlb_func_remote,
>> + flush_tlb_func_local,
>> (void *)info, 1);
>> }
>> }
>
> Do we really need that _local/_remote distinction? ISTR you had a patch
> that frobbed flush_tlb_info into the csd and that gave space
> constraints, but I'm not seeing that here (probably a wise, get stuff
> merged etc..).
>
> struct __call_single_data {
> struct llist_node llist; /* 0 8 */
> smp_call_func_t func; /* 8 8 */
> void * info; /* 16 8 */
> unsigned int flags; /* 24 4 */
>
> /* size: 32, cachelines: 1, members: 4 */
> /* padding: 4 */
> /* last cacheline: 32 bytes */
> };
>
> struct flush_tlb_info {
> struct mm_struct * mm; /* 0 8 */
> long unsigned int start; /* 8 8 */
> long unsigned int end; /* 16 8 */
> u64 new_tlb_gen; /* 24 8 */
> unsigned int stride_shift; /* 32 4 */
> bool freed_tables; /* 36 1 */
>
> /* size: 40, cachelines: 1, members: 6 */
> /* padding: 3 */
> /* last cacheline: 40 bytes */
> };
>
> IIRC what you did was make void *__call_single_data::info the last
> member and a union until the full cacheline size (64). Given the above
> that would get us 24 bytes for csd, leaving us 40 for that
> flush_tlb_info.
>
> But then we can still do something like the below, which doesn't change
> things and still gets rid of that dual function crud, simplifying
> smp_call_function_many again.
>
> Index: linux-2.6/arch/x86/include/asm/tlbflush.h
> ===================================================================
> --- linux-2.6.orig/arch/x86/include/asm/tlbflush.h
> +++ linux-2.6/arch/x86/include/asm/tlbflush.h
> @@ -546,8 +546,9 @@ struct flush_tlb_info {
> unsigned long start;
> unsigned long end;
> u64 new_tlb_gen;
> - unsigned int stride_shift;
> - bool freed_tables;
> + unsigned int cpu;
> + unsigned short stride_shift;
> + unsigned char freed_tables;
> };
>
> #define local_flush_tlb() __flush_tlb()
> Index: linux-2.6/arch/x86/mm/tlb.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/mm/tlb.c
> +++ linux-2.6/arch/x86/mm/tlb.c
> @@ -659,6 +659,27 @@ static void flush_tlb_func_remote(void *
> flush_tlb_func_common(f, false, TLB_REMOTE_SHOOTDOWN);
> }
>
> +static void flush_tlb_func(void *info)
> +{
> + const struct flush_tlb_info *f = info;
> + enum tlb_flush_reason reason = TLB_REMOTE_SHOOTDOWN;
> + bool local = false;
> +
> + if (f->cpu == smp_processor_id()) {
> + local = true;
> + reason = (f->mm == NULL) ? TLB_LOCAL_SHOOTDOWN : TLB_LOCAL_MM_SHOOTDOWN;
> + } else {
> + inc_irq_stat(irq_tlb_count);
> +
> + if (f->mm && f->mm != this_cpu_read(cpu_tlbstate.loaded_mm))
> + return;
> +
> + count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
> + }
> +
> + flush_tlb_func_common(f, local, reason);
> +}
> +
> static bool tlb_is_not_lazy(int cpu)
> {
> return !per_cpu(cpu_tlbstate_shared.is_lazy, cpu);
Nice! I will add it on top, if you don’t mind (instead squashing it).
The original decision to have local/remote functions was mostly to provide
the generality.
I would change the last argument of __smp_call_function_many() from “wait”
to “flags” that would indicate whether to run the function locally, since I
don’t want to change the semantics of smp_call_function_many() and decide
whether to run the function locally purely based on the mask. Let me know if
you disagree.
^ permalink raw reply
* Re: [PATCH v3 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
From: Peter Zijlstra @ 2019-07-22 19:32 UTC (permalink / raw)
To: Nadav Amit
Cc: Andy Lutomirski, Dave Hansen, the arch/x86 maintainers, LKML,
Thomas Gleixner, Ingo Molnar, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, Sasha Levin, Borislav Petkov, Juergen Gross,
Paolo Bonzini, Boris Ostrovsky, linux-hyperv@vger.kernel.org,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
xen-devel@lists.xenproject.org
In-Reply-To: <58DA0841-33C2-4D16-A671-08064A15001C@vmware.com>
On Mon, Jul 22, 2019 at 07:27:09PM +0000, Nadav Amit wrote:
> > On Jul 22, 2019, at 12:14 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > But then we can still do something like the below, which doesn't change
> > things and still gets rid of that dual function crud, simplifying
> > smp_call_function_many again.
> Nice! I will add it on top, if you don’t mind (instead squashing it).
Not at all.
> The original decision to have local/remote functions was mostly to provide
> the generality.
>
> I would change the last argument of __smp_call_function_many() from “wait”
> to “flags” that would indicate whether to run the function locally, since I
> don’t want to change the semantics of smp_call_function_many() and decide
> whether to run the function locally purely based on the mask. Let me know if
> you disagree.
Agreed.
^ permalink raw reply
* [PATCH v1] hv_sock: Use consistent types for UUIDs
From: Andy Shevchenko @ 2019-07-23 16:39 UTC (permalink / raw)
To: Haiyang Zhang, K. Y. Srinivasan, Stephen Hemminger, Sasha Levin,
linux-hyperv, David S. Miller, netdev
Cc: Andy Shevchenko
The rest of Hyper-V code is using new types for UUID handling.
Convert hv_sock as well.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
net/vmw_vsock/hyperv_transport.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index f2084e3f7aa4..2a1719c0f8d2 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -77,11 +77,11 @@ struct hvs_send_buf {
VMBUS_PKT_TRAILER_SIZE)
union hvs_service_id {
- uuid_le srv_id;
+ guid_t srv_id;
struct {
unsigned int svm_port;
- unsigned char b[sizeof(uuid_le) - sizeof(unsigned int)];
+ unsigned char b[sizeof(guid_t) - sizeof(unsigned int)];
};
};
@@ -89,8 +89,8 @@ union hvs_service_id {
struct hvsock {
struct vsock_sock *vsk;
- uuid_le vm_srv_id;
- uuid_le host_srv_id;
+ guid_t vm_srv_id;
+ guid_t host_srv_id;
struct vmbus_channel *chan;
struct vmpacket_descriptor *recv_desc;
@@ -159,21 +159,21 @@ struct hvsock {
#define MIN_HOST_EPHEMERAL_PORT (MAX_HOST_LISTEN_PORT + 1)
/* 00000000-facb-11e6-bd58-64006a7986d3 */
-static const uuid_le srv_id_template =
- UUID_LE(0x00000000, 0xfacb, 0x11e6, 0xbd, 0x58,
- 0x64, 0x00, 0x6a, 0x79, 0x86, 0xd3);
+static const guid_t srv_id_template =
+ GUID_INIT(0x00000000, 0xfacb, 0x11e6, 0xbd, 0x58,
+ 0x64, 0x00, 0x6a, 0x79, 0x86, 0xd3);
-static bool is_valid_srv_id(const uuid_le *id)
+static bool is_valid_srv_id(const guid_t *id)
{
- return !memcmp(&id->b[4], &srv_id_template.b[4], sizeof(uuid_le) - 4);
+ return !memcmp(&id->b[4], &srv_id_template.b[4], sizeof(guid_t) - 4);
}
-static unsigned int get_port_by_srv_id(const uuid_le *svr_id)
+static unsigned int get_port_by_srv_id(const guid_t *svr_id)
{
return *((unsigned int *)svr_id);
}
-static void hvs_addr_init(struct sockaddr_vm *addr, const uuid_le *svr_id)
+static void hvs_addr_init(struct sockaddr_vm *addr, const guid_t *svr_id)
{
unsigned int port = get_port_by_srv_id(svr_id);
@@ -316,7 +316,7 @@ static void hvs_close_connection(struct vmbus_channel *chan)
static void hvs_open_connection(struct vmbus_channel *chan)
{
- uuid_le *if_instance, *if_type;
+ guid_t *if_instance, *if_type;
unsigned char conn_from_host;
struct sockaddr_vm addr;
--
2.20.1
^ permalink raw reply related
* RE: [PATCH v1] hv_sock: Use consistent types for UUIDs
From: Dexuan Cui @ 2019-07-23 16:57 UTC (permalink / raw)
To: Andy Shevchenko, Haiyang Zhang, KY Srinivasan, Stephen Hemminger,
Sasha Levin, linux-hyperv@vger.kernel.org, David S. Miller,
netdev@vger.kernel.org
In-Reply-To: <20190723163943.65991-1-andriy.shevchenko@linux.intel.com>
> From: linux-hyperv-owner@vger.kernel.org
> <linux-hyperv-owner@vger.kernel.org> On Behalf Of Andy Shevchenko
> Sent: Tuesday, July 23, 2019 9:40 AM
>
> The rest of Hyper-V code is using new types for UUID handling.
> Convert hv_sock as well.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Looks good to me. Thanks, Andy!
Thanks,
-- Dexuan
^ permalink raw reply
* [PATCH net-next] Name NICs based on vmbus offer and enable async probe by default
From: Haiyang Zhang @ 2019-07-23 19:02 UTC (permalink / raw)
To: sashal@kernel.org, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org
Cc: Haiyang Zhang, KY Srinivasan, Stephen Hemminger, olaf@aepfle.de,
vkuznets, davem@davemloft.net, linux-kernel@vger.kernel.org
Previously the async probing caused NIC naming in random order.
The patch adds a dev_num field in vmbus channel structure. It’s assigned
to the first available number when the channel is offered. So netvsc can
use it for NIC naming based on channel offer sequence. Now we re-enable
the async probing mode by default for faster probing.
Also added a modules parameter, probe_type, to set sync probing mode if
a user wants to.
Fixes: af0a5646cb8d ("use the new async probing feature for the hyperv drivers")
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/hv/channel_mgmt.c | 46 +++++++++++++++++++++++++++++++++++++++--
drivers/net/hyperv/netvsc_drv.c | 33 ++++++++++++++++++++++++++---
include/linux/hyperv.h | 4 ++++
3 files changed, 78 insertions(+), 5 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index addcef5..ab7c05b 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -304,6 +304,8 @@ bool vmbus_prep_negotiate_resp(struct icmsg_hdr *icmsghdrp,
EXPORT_SYMBOL_GPL(vmbus_prep_negotiate_resp);
+#define HV_DEV_NUM_INVALID (-1)
+
/*
* alloc_channel - Allocate and initialize a vmbus channel object
*/
@@ -315,6 +317,8 @@ static struct vmbus_channel *alloc_channel(void)
if (!channel)
return NULL;
+ channel->dev_num = HV_DEV_NUM_INVALID;
+
spin_lock_init(&channel->lock);
init_completion(&channel->rescind_event);
@@ -533,6 +537,42 @@ static void vmbus_add_channel_work(struct work_struct *work)
}
/*
+ * Get the first available device number of its type, then
+ * record it in the channel structure.
+ */
+static void hv_set_devnum(struct vmbus_channel *newchannel)
+{
+ struct vmbus_channel *channel;
+ unsigned int i = 0;
+ bool found;
+
+ BUG_ON(!mutex_is_locked(&vmbus_connection.channel_mutex));
+
+ /* Only HV_NIC uses this number for now */
+ if (hv_get_dev_type(newchannel) != HV_NIC)
+ return;
+
+next:
+ found = false;
+
+ list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
+ if (i == channel->dev_num &&
+ guid_equal(&channel->offermsg.offer.if_type,
+ &newchannel->offermsg.offer.if_type)) {
+ found = true;
+ break;
+ }
+ }
+
+ if (found) {
+ i++;
+ goto next;
+ }
+
+ newchannel->dev_num = i;
+}
+
+/*
* vmbus_process_offer - Process the offer by creating a channel/device
* associated with this offer
*/
@@ -561,10 +601,12 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel)
}
}
- if (fnew)
+ if (fnew) {
+ hv_set_devnum(newchannel);
+
list_add_tail(&newchannel->listentry,
&vmbus_connection.chn_list);
- else {
+ } else {
/*
* Check to see if this is a valid sub-channel.
*/
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index afdcc56..af53690 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -57,6 +57,10 @@
module_param(debug, int, 0444);
MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+static unsigned int probe_type __ro_after_init = PROBE_PREFER_ASYNCHRONOUS;
+module_param(probe_type, uint, 0444);
+MODULE_PARM_DESC(probe_type, "Probe type: 1=async(default), 2=sync");
+
static LIST_HEAD(netvsc_dev_list);
static void netvsc_change_rx_flags(struct net_device *net, int change)
@@ -2233,10 +2237,19 @@ static int netvsc_probe(struct hv_device *dev,
struct net_device_context *net_device_ctx;
struct netvsc_device_info *device_info = NULL;
struct netvsc_device *nvdev;
+ char name[IFNAMSIZ];
int ret = -ENOMEM;
- net = alloc_etherdev_mq(sizeof(struct net_device_context),
- VRSS_CHANNEL_MAX);
+ if (probe_type == PROBE_PREFER_ASYNCHRONOUS) {
+ snprintf(name, IFNAMSIZ, "eth%d", dev->channel->dev_num);
+ net = alloc_netdev_mqs(sizeof(struct net_device_context), name,
+ NET_NAME_ENUM, ether_setup,
+ VRSS_CHANNEL_MAX, VRSS_CHANNEL_MAX);
+ } else {
+ net = alloc_etherdev_mq(sizeof(struct net_device_context),
+ VRSS_CHANNEL_MAX);
+ }
+
if (!net)
goto no_net;
@@ -2323,6 +2336,14 @@ static int netvsc_probe(struct hv_device *dev,
net->max_mtu = ETH_DATA_LEN;
ret = register_netdevice(net);
+
+ if (ret == -EEXIST) {
+ pr_info("NIC name %s exists, request another name.\n",
+ net->name);
+ strlcpy(net->name, "eth%d", IFNAMSIZ);
+ ret = register_netdevice(net);
+ }
+
if (ret != 0) {
pr_err("Unable to register netdev.\n");
goto register_failed;
@@ -2407,7 +2428,7 @@ static int netvsc_remove(struct hv_device *dev)
.probe = netvsc_probe,
.remove = netvsc_remove,
.driver = {
- .probe_type = PROBE_FORCE_SYNCHRONOUS,
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
},
};
@@ -2473,6 +2494,12 @@ static int __init netvsc_drv_init(void)
}
netvsc_ring_bytes = ring_size * PAGE_SIZE;
+ if (probe_type != PROBE_PREFER_ASYNCHRONOUS)
+ probe_type = PROBE_FORCE_SYNCHRONOUS;
+
+ netvsc_drv.driver.probe_type = probe_type;
+ pr_info("probe_type: %u\n", probe_type);
+
ret = vmbus_driver_register(&netvsc_drv);
if (ret)
return ret;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 6256cc3..12fc5ea 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -841,6 +841,10 @@ struct vmbus_channel {
*/
struct vmbus_channel *primary_channel;
/*
+ * Used for device naming based on channel offer sequence.
+ */
+ int dev_num;
+ /*
* Support per-channel state for use by vmbus drivers.
*/
void *per_channel_state;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v1] hv_sock: Use consistent types for UUIDs
From: David Miller @ 2019-07-23 20:58 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: haiyangz, kys, sthemmin, sashal, linux-hyperv, netdev
In-Reply-To: <20190723163943.65991-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 23 Jul 2019 19:39:43 +0300
> The rest of Hyper-V code is using new types for UUID handling.
> Convert hv_sock as well.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH v3] locking/spinlocks, paravirt, hyperv: Correct the hv_nopvspin case
From: Zhenzhong Duan @ 2019-07-24 7:29 UTC (permalink / raw)
To: linux-kernel
Cc: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
Juergen Gross, Boris Ostrovsky, Peter Zijlstra, Waiman Long,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, linux-hyperv
In-Reply-To: <1562120635-9806-1-git-send-email-zhenzhong.duan@oracle.com>
Hi Maintainers,
Any further comments on this? Thanks
Zhenzhong
On 2019/7/3 10:23, Zhenzhong Duan wrote:
> With the boot parameter "hv_nopvspin" specified a Hyperv guest should
> not make use of paravirt spinlocks, but behave as if running on bare
> metal. This is not true, however, as the qspinlock code will fall back
> to a test-and-set scheme when it is detecting a hypervisor.
>
> In order to avoid this disable the virt_spin_lock_key.
>
> Same change for XEN is already in Commit e6fd28eb3522
> ("locking/spinlocks, paravirt, xen: Correct the xen_nopvspin case")
>
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
> Cc: "K. Y. Srinivasan" <kys@microsoft.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>
> Cc: Stephen Hemminger <sthemmin@microsoft.com>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Waiman Long <longman@redhat.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: linux-hyperv@vger.kernel.org
> ---
> v3: remove unlikely() as suggested by Sasha
>
> arch/x86/hyperv/hv_spinlock.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
> index 07f21a0..210495b 100644
> --- a/arch/x86/hyperv/hv_spinlock.c
> +++ b/arch/x86/hyperv/hv_spinlock.c
> @@ -64,6 +64,9 @@ __visible bool hv_vcpu_is_preempted(int vcpu)
>
> void __init hv_init_spinlocks(void)
> {
> + if (!hv_pvspin)
> + static_branch_disable(&virt_spin_lock_key);
> +
> if (!hv_pvspin || !apic ||
> !(ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) ||
> !(ms_hyperv.features & HV_X64_MSR_GUEST_IDLE_AVAILABLE)) {
^ permalink raw reply
* [PATCH 0/2] Drivers: hv: Specify buffer size using Hyper-V page size
From: Himadri Pandya @ 2019-07-25 5:03 UTC (permalink / raw)
To: mikelley, kys, haiyangz, sthemmin, sashal
Cc: linux-hyperv, linux-kernel, Himadri Pandya
recv_buffer and VMbus ring buffers are sized based on guest page size
which Hyper-V assumes to be 4KB. It might not be the case for some
architectures. Hence instead use the Hyper-V page size.
Himadri Pandya (2):
Drivers: hv: Specify receive buffer size using Hyper-V page size
Drivers: hv: util: Specify ring buffer size using Hyper-V page size
drivers/hv/hv_fcopy.c | 3 ++-
drivers/hv/hv_kvp.c | 3 ++-
drivers/hv/hv_snapshot.c | 3 ++-
drivers/hv/hv_util.c | 13 +++++++------
4 files changed, 13 insertions(+), 9 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/2] Drivers: hv: Specify receive buffer size using Hyper-V page size
From: Himadri Pandya @ 2019-07-25 5:03 UTC (permalink / raw)
To: mikelley, kys, haiyangz, sthemmin, sashal
Cc: linux-hyperv, linux-kernel, Himadri Pandya
In-Reply-To: <20190725050315.6935-1-himadri18.07@gmail.com>
The recv_buffer is used to retrieve data from the VMbus ring buffer.
VMbus ring buffers are sized based on the guest page size which
Hyper-V assumes to be 4KB. But it may be different on some
architectures. So use the Hyper-V page size to allocate the
recv_buffer and set the maximum size to receive.
Signed-off-by: Himadri Pandya <himadri18.07@gmail.com>
---
drivers/hv/hv_fcopy.c | 3 ++-
drivers/hv/hv_kvp.c | 3 ++-
drivers/hv/hv_snapshot.c | 3 ++-
drivers/hv/hv_util.c | 8 ++++----
4 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
index 7e30ae0635cc..08fa4a5de644 100644
--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -13,6 +13,7 @@
#include <linux/workqueue.h>
#include <linux/hyperv.h>
#include <linux/sched.h>
+#include <asm/hyperv-tlfs.h>
#include "hyperv_vmbus.h"
#include "hv_utils_transport.h"
@@ -234,7 +235,7 @@ void hv_fcopy_onchannelcallback(void *context)
if (fcopy_transaction.state > HVUTIL_READY)
return;
- vmbus_recvpacket(channel, recv_buffer, PAGE_SIZE * 2, &recvlen,
+ vmbus_recvpacket(channel, recv_buffer, HV_HYP_PAGE_SIZE * 2, &recvlen,
&requestid);
if (recvlen <= 0)
return;
diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index 5054d1105236..ae7c028dc5a8 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -27,6 +27,7 @@
#include <linux/connector.h>
#include <linux/workqueue.h>
#include <linux/hyperv.h>
+#include <asm/hyperv-tlfs.h>
#include "hyperv_vmbus.h"
#include "hv_utils_transport.h"
@@ -661,7 +662,7 @@ void hv_kvp_onchannelcallback(void *context)
if (kvp_transaction.state > HVUTIL_READY)
return;
- vmbus_recvpacket(channel, recv_buffer, PAGE_SIZE * 4, &recvlen,
+ vmbus_recvpacket(channel, recv_buffer, HV_HYP_PAGE_SIZE * 4, &recvlen,
&requestid);
if (recvlen > 0) {
diff --git a/drivers/hv/hv_snapshot.c b/drivers/hv/hv_snapshot.c
index 20ba95b75a94..03b6454268b3 100644
--- a/drivers/hv/hv_snapshot.c
+++ b/drivers/hv/hv_snapshot.c
@@ -12,6 +12,7 @@
#include <linux/connector.h>
#include <linux/workqueue.h>
#include <linux/hyperv.h>
+#include <asm/hyperv-tlfs.h>
#include "hyperv_vmbus.h"
#include "hv_utils_transport.h"
@@ -297,7 +298,7 @@ void hv_vss_onchannelcallback(void *context)
if (vss_transaction.state > HVUTIL_READY)
return;
- vmbus_recvpacket(channel, recv_buffer, PAGE_SIZE * 2, &recvlen,
+ vmbus_recvpacket(channel, recv_buffer, HV_HYP_PAGE_SIZE * 2, &recvlen,
&requestid);
if (recvlen > 0) {
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index e32681ee7b9f..c2c08f26bd5f 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -136,7 +136,7 @@ static void shutdown_onchannelcallback(void *context)
struct icmsg_hdr *icmsghdrp;
vmbus_recvpacket(channel, shut_txf_buf,
- PAGE_SIZE, &recvlen, &requestid);
+ HV_HYP_PAGE_SIZE, &recvlen, &requestid);
if (recvlen > 0) {
icmsghdrp = (struct icmsg_hdr *)&shut_txf_buf[
@@ -284,7 +284,7 @@ static void timesync_onchannelcallback(void *context)
u8 *time_txf_buf = util_timesynch.recv_buffer;
vmbus_recvpacket(channel, time_txf_buf,
- PAGE_SIZE, &recvlen, &requestid);
+ HV_HYP_PAGE_SIZE, &recvlen, &requestid);
if (recvlen > 0) {
icmsghdrp = (struct icmsg_hdr *)&time_txf_buf[
@@ -346,7 +346,7 @@ static void heartbeat_onchannelcallback(void *context)
while (1) {
vmbus_recvpacket(channel, hbeat_txf_buf,
- PAGE_SIZE, &recvlen, &requestid);
+ HV_HYP_PAGE_SIZE, &recvlen, &requestid);
if (!recvlen)
break;
@@ -390,7 +390,7 @@ static int util_probe(struct hv_device *dev,
(struct hv_util_service *)dev_id->driver_data;
int ret;
- srv->recv_buffer = kmalloc(PAGE_SIZE * 4, GFP_KERNEL);
+ srv->recv_buffer = kmalloc(HV_HYP_PAGE_SIZE * 4, GFP_KERNEL);
if (!srv->recv_buffer)
return -ENOMEM;
srv->channel = dev->channel;
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] Drivers: hv: util: Specify ring buffer size using Hyper-V page size
From: Himadri Pandya @ 2019-07-25 5:03 UTC (permalink / raw)
To: mikelley, kys, haiyangz, sthemmin, sashal
Cc: linux-hyperv, linux-kernel, Himadri Pandya
In-Reply-To: <20190725050315.6935-1-himadri18.07@gmail.com>
VMbus ring buffers are sized based on the 4K page size used by
Hyper-V. The Linux guest page size may not be 4K on all architectures
so use the Hyper-V page size to specify the ring buffer size.
Signed-off-by: Himadri Pandya <himadri18.07@gmail.com>
---
drivers/hv/hv_util.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index c2c08f26bd5f..766bd8457346 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -413,8 +413,9 @@ static int util_probe(struct hv_device *dev,
hv_set_drvdata(dev, srv);
- ret = vmbus_open(dev->channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL, 0,
- srv->util_cb, dev->channel);
+ ret = vmbus_open(dev->channel, 4 * HV_HYP_PAGE_SIZE,
+ 4 * HV_HYP_PAGE_SIZE, NULL, 0, srv->util_cb,
+ dev->channel);
if (ret)
goto error;
--
2.17.1
^ permalink raw reply related
* [PATCH] hv_sock: use HV_HYP_PAGE_SIZE instead of PAGE_SIZE_4K
From: Himadri Pandya @ 2019-07-25 5:11 UTC (permalink / raw)
To: mikelley, kys, haiyangz, sthemmin, sashal, davem
Cc: linux-hyperv, netdev, linux-kernel, Himadri Pandya
Older windows hosts require the hv_sock ring buffer to be defined
using 4K pages. This was achieved by using the symbol PAGE_SIZE_4K
defined specifically for this purpose. But now we have a new symbol
HV_HYP_PAGE_SIZE defined in hyperv-tlfs which can be used for this.
This patch removes the definition of symbol PAGE_SIZE_4K and replaces
its usage with the symbol HV_HYP_PAGE_SIZE. This patch also aligns
sndbuf and rcvbuf to hyper-v specific page size using HV_HYP_PAGE_SIZE
instead of the guest page size(PAGE_SIZE) as hyper-v expects the page
size to be 4K and it might not be the case on ARM64 architecture.
Signed-off-by: Himadri Pandya <himadri18.07@gmail.com>
---
net/vmw_vsock/hyperv_transport.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index f2084e3f7aa4..ecb5d72d8010 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -13,15 +13,16 @@
#include <linux/hyperv.h>
#include <net/sock.h>
#include <net/af_vsock.h>
+#include <asm/hyperv-tlfs.h>
/* Older (VMBUS version 'VERSION_WIN10' or before) Windows hosts have some
- * stricter requirements on the hv_sock ring buffer size of six 4K pages. Newer
- * hosts don't have this limitation; but, keep the defaults the same for compat.
+ * stricter requirements on the hv_sock ring buffer size of six 4K pages.
+ * hyperv-tlfs defines HV_HYP_PAGE_SIZE as 4K. Newer hosts don't have this
+ * limitation; but, keep the defaults the same for compat.
*/
-#define PAGE_SIZE_4K 4096
-#define RINGBUFFER_HVS_RCV_SIZE (PAGE_SIZE_4K * 6)
-#define RINGBUFFER_HVS_SND_SIZE (PAGE_SIZE_4K * 6)
-#define RINGBUFFER_HVS_MAX_SIZE (PAGE_SIZE_4K * 64)
+#define RINGBUFFER_HVS_RCV_SIZE (HV_HYP_PAGE_SIZE * 6)
+#define RINGBUFFER_HVS_SND_SIZE (HV_HYP_PAGE_SIZE * 6)
+#define RINGBUFFER_HVS_MAX_SIZE (HV_HYP_PAGE_SIZE * 64)
/* The MTU is 16KB per the host side's design */
#define HVS_MTU_SIZE (1024 * 16)
@@ -54,7 +55,7 @@ struct hvs_recv_buf {
* ringbuffer APIs that allow us to directly copy data from userspace buffer
* to VMBus ringbuffer.
*/
-#define HVS_SEND_BUF_SIZE (PAGE_SIZE_4K - sizeof(struct vmpipe_proto_header))
+#define HVS_SEND_BUF_SIZE (HV_HYP_PAGE_SIZE - sizeof(struct vmpipe_proto_header))
struct hvs_send_buf {
/* The header before the payload data */
@@ -388,10 +389,10 @@ static void hvs_open_connection(struct vmbus_channel *chan)
} else {
sndbuf = max_t(int, sk->sk_sndbuf, RINGBUFFER_HVS_SND_SIZE);
sndbuf = min_t(int, sndbuf, RINGBUFFER_HVS_MAX_SIZE);
- sndbuf = ALIGN(sndbuf, PAGE_SIZE);
+ sndbuf = ALIGN(sndbuf, HV_HYP_PAGE_SIZE);
rcvbuf = max_t(int, sk->sk_rcvbuf, RINGBUFFER_HVS_RCV_SIZE);
rcvbuf = min_t(int, rcvbuf, RINGBUFFER_HVS_MAX_SIZE);
- rcvbuf = ALIGN(rcvbuf, PAGE_SIZE);
+ rcvbuf = ALIGN(rcvbuf, HV_HYP_PAGE_SIZE);
}
ret = vmbus_open(chan, sndbuf, rcvbuf, NULL, 0, hvs_channel_cb,
@@ -662,7 +663,7 @@ static ssize_t hvs_stream_enqueue(struct vsock_sock *vsk, struct msghdr *msg,
ssize_t ret = 0;
ssize_t bytes_written = 0;
- BUILD_BUG_ON(sizeof(*send_buf) != PAGE_SIZE_4K);
+ BUILD_BUG_ON(sizeof(*send_buf) != HV_HYP_PAGE_SIZE);
send_buf = kmalloc(sizeof(*send_buf), GFP_KERNEL);
if (!send_buf)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next] Name NICs based on vmbus offer and enable async probe by default
From: David Miller @ 2019-07-25 18:46 UTC (permalink / raw)
To: haiyangz
Cc: sashal, linux-hyperv, netdev, kys, sthemmin, olaf, vkuznets,
linux-kernel
In-Reply-To: <1563908517-55735-1-git-send-email-haiyangz@microsoft.com>
1) Subject: line lacks proper subsystem prefix
2) No module parameters in networking drivers, sorry. Find some generic way to do
this via devlink or similar.
^ permalink raw reply
* Re: [PATCH] hv_sock: use HV_HYP_PAGE_SIZE instead of PAGE_SIZE_4K
From: David Miller @ 2019-07-26 0:26 UTC (permalink / raw)
To: himadrispandya
Cc: mikelley, kys, haiyangz, sthemmin, sashal, linux-hyperv, netdev,
linux-kernel, himadri18.07
In-Reply-To: <20190725051125.10605-1-himadri18.07@gmail.com>
From: Himadri Pandya <himadrispandya@gmail.com>
Date: Thu, 25 Jul 2019 05:11:25 +0000
> Older windows hosts require the hv_sock ring buffer to be defined
> using 4K pages. This was achieved by using the symbol PAGE_SIZE_4K
> defined specifically for this purpose. But now we have a new symbol
> HV_HYP_PAGE_SIZE defined in hyperv-tlfs which can be used for this.
>
> This patch removes the definition of symbol PAGE_SIZE_4K and replaces
> its usage with the symbol HV_HYP_PAGE_SIZE. This patch also aligns
> sndbuf and rcvbuf to hyper-v specific page size using HV_HYP_PAGE_SIZE
> instead of the guest page size(PAGE_SIZE) as hyper-v expects the page
> size to be 4K and it might not be the case on ARM64 architecture.
>
> Signed-off-by: Himadri Pandya <himadri18.07@gmail.com>
This doesn't compile:
CC [M] net/vmw_vsock/hyperv_transport.o
net/vmw_vsock/hyperv_transport.c:58:28: error: ‘HV_HYP_PAGE_SIZE’ undeclared here (not in a function); did you mean ‘HV_MESSAGE_SIZE’?
#define HVS_SEND_BUF_SIZE (HV_HYP_PAGE_SIZE - sizeof(struct vmpipe_proto_header))
^~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCH v3 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
From: Juergen Gross @ 2019-07-26 7:28 UTC (permalink / raw)
To: Nadav Amit, Andy Lutomirski, Dave Hansen
Cc: Borislav Petkov, Peter Zijlstra, Sasha Levin, x86,
Thomas Gleixner, virtualization, xen-devel, Haiyang Zhang,
K. Y. Srinivasan, Stephen Hemminger, Boris Ostrovsky, Ingo Molnar,
Paolo Bonzini, kvm, linux-hyperv, linux-kernel
In-Reply-To: <20190719005837.4150-5-namit@vmware.com>
On 19.07.19 02:58, Nadav Amit wrote:
> To improve TLB shootdown performance, flush the remote and local TLBs
> concurrently. Introduce flush_tlb_multi() that does so. Introduce
> paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen
> and hyper-v are only compile-tested).
>
> While the updated smp infrastructure is capable of running a function on
> a single local core, it is not optimized for this case. The multiple
> function calls and the indirect branch introduce some overhead, and
> might make local TLB flushes slower than they were before the recent
> changes.
>
> Before calling the SMP infrastructure, check if only a local TLB flush
> is needed to restore the lost performance in this common case. This
> requires to check mm_cpumask() one more time, but unless this mask is
> updated very frequently, this should impact performance negatively.
>
> Cc: "K. Y. Srinivasan" <kys@microsoft.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>
> Cc: Stephen Hemminger <sthemmin@microsoft.com>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: linux-hyperv@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: virtualization@lists.linux-foundation.org
> Cc: kvm@vger.kernel.org
> Cc: xen-devel@lists.xenproject.org
> Signed-off-by: Nadav Amit <namit@vmware.com>
> ---
> arch/x86/hyperv/mmu.c | 10 +++---
> arch/x86/include/asm/paravirt.h | 6 ++--
> arch/x86/include/asm/paravirt_types.h | 4 +--
> arch/x86/include/asm/tlbflush.h | 8 ++---
> arch/x86/include/asm/trace/hyperv.h | 2 +-
> arch/x86/kernel/kvm.c | 11 +++++--
> arch/x86/kernel/paravirt.c | 2 +-
> arch/x86/mm/tlb.c | 47 ++++++++++++++++++---------
> arch/x86/xen/mmu_pv.c | 11 +++----
> include/trace/events/xen.h | 2 +-
> 10 files changed, 62 insertions(+), 41 deletions(-)
Xen and paravirt parts: Reviewed-by: Juergen Gross <jgross@suse.com>
Juergen
^ permalink raw reply
* Re: [PATCH 2/2] Drivers: hv: util: Specify ring buffer size using Hyper-V page size
From: Stephen Hemminger @ 2019-07-26 16:06 UTC (permalink / raw)
To: Himadri Pandya
Cc: Michael Kelley, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal, linux-hyperv, linux-kernel, himadri18.07
In-Reply-To: <20190725050315.6935-3-himadri18.07@gmail.com>
On Wed, 24 Jul 2019 22:03:15 -0700
"Himadri Pandya" <himadrispandya@gmail.com> wrote:
> VMbus ring buffers are sized based on the 4K page size used by
> Hyper-V. The Linux guest page size may not be 4K on all architectures
> so use the Hyper-V page size to specify the ring buffer size.
>
> Signed-off-by: Himadri Pandya <himadri18.07@gmail.com>
> ---
> drivers/hv/hv_util.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
> index c2c08f26bd5f..766bd8457346 100644
> --- a/drivers/hv/hv_util.c
> +++ b/drivers/hv/hv_util.c
> @@ -413,8 +413,9 @@ static int util_probe(struct hv_device *dev,
>
> hv_set_drvdata(dev, srv);
>
> - ret = vmbus_open(dev->channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL,
> 0,
> - srv->util_cb, dev->channel);
> + ret = vmbus_open(dev->channel, 4 * HV_HYP_PAGE_SIZE,
> + 4 * HV_HYP_PAGE_SIZE, NULL, 0, srv->util_cb,
> + dev->channel);
> if (ret)
> goto error;
>
hv_util doesn't need lots of buffering. Why not define a fixed
value across all architectures. Maybe with some roundup to HV_HYP_PAGE_SIZE.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox