date:20201202

On Wed, Dec 02, 2020 at 09:48:25PM +0800, Jason Wang wrote:
> 
> On 2020/12/2 下午5:23, Michael S. Tsirkin wrote:
> > On Wed, Dec 02, 2020 at 07:57:14AM +0200, Eli Cohen wrote:
> > > On Wed, Dec 02, 2020 at 12:18:36PM +0800, Jason Wang wrote:
> > > > On 2020/12/1 下午5:23, Cindy Lu wrote:
> > > > > On Mon, Nov 30, 2020 at 11:33 PM Michael S. Tsirkin  
> > > > > wrote:
> > > > > > On Mon, Nov 30, 2020 at 06:41:45PM +0800, Cindy Lu wrote:
> > > > > > > On Mon, Nov 30, 2020 at 5:33 PM Michael S. 
> > > > > > > Tsirkin  wrote:
> > > > > > > > On Mon, Nov 30, 2020 at 11:27:59AM +0200, Eli Cohen wrote:
> > > > > > > > > On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. Tsirkin 
> > > > > > > > > wrote:
> > > > > > > > > > On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:
> > > > > > > > > > > On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. 
> > > > > > > > > > > Tsirkin wrote:
> > > > > > > > > > > > On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > We should not try to use the VF MAC address as that 
> > > > > > > > > > > > > is used by the
> > > > > > > > > > > > > regular (e.g. mlx5_core) NIC implementation. Instead, 
> > > > > > > > > > > > > use a random
> > > > > > > > > > > > > generated MAC address.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Suggested by: Cindy Lu
> > > > > > > > > > > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for 
> > > > > > > > > > > > > supported mlx5 devices")
> > > > > > > > > > > > > Signed-off-by: Eli Cohen
> > > > > > > > > > > > I didn't realise it's possible to use VF in two ways
> > > > > > > > > > > > with and without vdpa.
> > > > > > > > > > > Using a VF you can create quite a few resources, e.g. 
> > > > > > > > > > > send queues
> > > > > > > > > > > recieve queues, virtio_net queues etc. So you can 
> > > > > > > > > > > possibly create
> > > > > > > > > > > several instances of vdpa net devices and nic net devices.
> > > > > > > > > > > 
> > > > > > > > > > > > Could you include a bit more description on the failure
> > > > > > > > > > > > mode?
> > > > > > > > > > > Well, using the MAC address of the nic vport is wrong 
> > > > > > > > > > > since that is the
> > > > > > > > > > > MAC of the regular NIC implementation of mlx5_core.
> > > > > > > > > > Right but ATM it doesn't coexist with vdpa so what's the 
> > > > > > > > > > problem?
> > > > > > > > > > 
> > > > > > > > > This call is wrong:  mlx5_query_nic_vport_mac_address()
> > > > > > > > > 
> > > > > > > > > > > > Is switching to a random mac for such an unusual
> > > > > > > > > > > > configuration really justified?
> > > > > > > > > > > Since I can't use the NIC's MAC address, I have two 
> > > > > > > > > > > options:
> > > > > > > > > > > 1. To get the MAC address as was chosen by the user 
> > > > > > > > > > > administering the
> > > > > > > > > > >  NIC. This should invoke the set_config callback. 
> > > > > > > > > > > Unfortunately this
> > > > > > > > > > >  is not implemented yet.
> > > > > > > > > > > 
> > > > > > > > > > > 2. Use a random MAC address. This is OK since if (1) is 
> > > > > > > > > > > implemented it
> > > > > > > > > > >  can always override this random configuration.
> > > > > > > > > > > 
> > > > > > > > > > > > It looks like changing a MAC could break some guests,
> > > > > > > > > > > > can it not?
> > > > > > > > > > > > 
> > > > > > > > > > > No, it will not. The current version of mlx5 VDPA does 
> > > > > > > > > > > not allow regular
> > > > > > > > > > > NIC driver and VDPA to co-exist. I have patches ready 
> > > > > > > > > > > that enable that
> > > > > > > > > > > from steering point of view. I will post them here once 
> > > > > > > > > > > other patches on
> > > > > > > > > > > which they depend will be merged.
> > > > > > > > > > > 
> > > > > > > > > > > https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/
> > > > > > > > > > Could you be more explicit on the following points:
> > > > > > > > > > - which configuration is broken ATM (as in, two device have 
> > > > > > > > > > identical
> > > > > > > > > > macs? any other issues)?
> > > > > > > > > The only wrong thing is the call to  
> > > > > > > > > mlx5_query_nic_vport_mac_address().
> > > > > > > > > It's not breaking anything yet is wrong. The random MAC 
> > > > > > > > > address setting
> > > > > > > > > is required for the steering patches.
> > > > > > > > Okay so I'm not sure the Fixes tag at least is appropriate if 
> > > > > > > > it's a
> > > > > > > > dependency of a new feature.
> > > > > > > > 
> > > > > > > > > > - why won't device MAC change from guest point of view?
> > > > > > > > > > 
> > > > > > > > > It's lack of implementation in qemu as far as I know.
> > > > > > > > Sorry not sure I understand. What's not implemented in QEMU?
> > > > > > > > 
> > > > > > > HI Michael, there are some bug in qemu to set_config, this will 
> > > > > > > fix in

Re: [GIT PULL] vdpa: last minute bugfixes

2020-12-02 Thread pr-tracker-bot

The pull request you sent on Wed, 2 Dec 2020 06:51:47 -0500:

> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2c6ffa9e9b11bdfa267fe05ad1e98d3491b4224f

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 04/12] x86/xen: drop USERGS_SYSRET64 paravirt call

2020-12-02 Thread Borislav Petkov

On Wed, Dec 02, 2020 at 03:48:21PM +0100, Jürgen Groß wrote:
> I wanted to avoid the additional NOPs for the bare metal case.

Yeah, in that case it gets optimized to a single NOP:

[0.176692] SMP alternatives: 81a00068: [0:5) optimized NOPs: 0f 1f 
44 00 00

which is nopl 0x0(%rax,%rax,1) and I don't think that's noticeable on
modern CPUs where a NOP is basically a rIP increment only and that goes
down the pipe almost for free. :-)

> If you don't mind them I can do as you are suggesting.

Yes pls, I think asm readability is more important than a 5-byte NOP.

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

2020-12-02 Thread Daniel Vetter

On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin  wrote:
>
>
>
> > On Dec 2, 2020, at 09:27, Thomas Zimmermann  wrote:
> >
> > Hi
> >
> > Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:
> >> Hi
> >> Am 30.11.20 um 21:59 schrieb Zack Rusin:
> >>>
> >>>
>  On Nov 24, 2020, at 06:38, Thomas Zimmermann  wrote:
> 
>  Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
>  drm_device.dev. No functional changes.
> 
>  Signed-off-by: Thomas Zimmermann 
>  Cc: Roland Scheidegger 
>  ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-
> >>>
> >>> Reviewed-by: Zack Rusin 
> >> Could you add this patch to the vmwgfx tree?
> >
> > AMD devs indicated that they'd prefer to merge the patchset trough 
> > drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through 
> > drm-misc-next as well.
>
> Sounds good. I’ll make sure to rebase our latest patch set on top of it when 
> it’s in. Thanks!

btw if you want to avoid multi-tree coordination headaches, we can
also manage vmwgfx in drm-misc and give you & Roland commit rights
there. Up to you. There is some scripting involved for now (but I hope
whenever we move to gitlab we could do the checks server-side):

https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 16/17] x86/ioapic: export a few functions and data structures via io_apic.h

2020-12-02 Thread Andy Shevchenko

On Wed, Dec 02, 2020 at 02:11:07PM +, Wei Liu wrote:
> On Wed, Nov 25, 2020 at 12:26:12PM +0200, Andy Shevchenko wrote:
> > On Wed, Nov 25, 2020 at 1:46 AM Wei Liu  wrote:
> > >
> > > We are about to implement an irqchip for IO-APIC when Linux runs as root
> > > on Microsoft Hypervisor. At the same time we would like to reuse
> > > existing code as much as possible.
> > >
> > > Move mp_chip_data to io_apic.h and make a few helper functions
> > > non-static.
> > 
> > > +struct mp_chip_data {
> > > +   struct list_head irq_2_pin;
> > > +   struct IO_APIC_route_entry entry;
> > > +   int trigger;
> > > +   int polarity;
> > > +   u32 count;
> > > +   bool isa_irq;
> > > +};
> > 
> > Since I see only this patch I am puzzled why you need to have this in
> > the header?
> > Maybe a couple of words in the commit message to elaborate?
> 
> Andy, does the following answer your question?
> 
> "The chip_data stashed in IO-APIC's irq chip is mp_chip_data.  The
> implementation of Microsoft Hypevisor's IO-APIC irqdomain would like to
> manipulate that data structure, so move it to io_apic.h as well."

At least it sheds some light, thanks.

> If that's good enough, I can add it to the commit message.

It's good for a starter, but I think you have to wait for what Thomas and other
related people can say.


-- 
With Best Regards,
Andy Shevchenko


___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 1/1 V2] vhost scsi: fix lun reset completion handling

2020-12-02 Thread Stefan Hajnoczi

On Wed, Nov 18, 2020 at 10:27:37AM -0600, Mike Christie wrote:
> vhost scsi owns the scsi se_cmd but lio frees the se_cmd->se_tmr
> before calling release_cmd, so while with normal cmd completion we
> can access the se_cmd from the vhost work, we can't do the same with
> se_cmd->se_tmr. This has us copy the tmf response in
> vhost_scsi_queue_tm_rsp to our internal vhost-scsi tmf struct for
> when it gets sent to the guest from our worker thread.
> 
> Fixes: Fixes: efd838fec17b ("vhost scsi: Add support for LUN resets.")
> Signed-off-by: Mike Christie 
> Acked-by: Stefan Hajnoczi 
> ---
> 
> V2:
> - Added fixes line.
> 
>  drivers/vhost/scsi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Acked-by: Stefan Hajnoczi 

This will go through Michael Tsirkin or Martin K. Petersen's tree.


signature.asc
Description: PGP signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 04/12] x86/xen: drop USERGS_SYSRET64 paravirt call

2020-12-02 Thread Jürgen Groß via Virtualization


On 02.12.20 13:32, Borislav Petkov wrote:

On Fri, Nov 20, 2020 at 12:46:22PM +0100, Juergen Gross wrote:

@@ -123,12 +115,15 @@ SYM_INNER_LABEL(entry_SYSCALL_64_after_hwframe, 
SYM_L_GLOBAL)
 * Try to use SYSRET instead of IRET if we're returning to
 * a completely clean 64-bit userspace context.  If we're not,
 * go to the slow exit path.
+* In the Xen PV case we must use iret anyway.
 */
-   movqRCX(%rsp), %rcx
-   movqRIP(%rsp), %r11
  
-	cmpq	%rcx, %r11	/* SYSRET requires RCX == RIP */

-   jne swapgs_restore_regs_and_return_to_usermode
+   ALTERNATIVE __stringify( \
+   movqRCX(%rsp), %rcx; \
+   movqRIP(%rsp), %r11; \
+   cmpq%rcx, %r11; /* SYSRET requires RCX == RIP */ \
+   jne swapgs_restore_regs_and_return_to_usermode), \
+   "jmp   swapgs_restore_regs_and_return_to_usermode", 
X86_FEATURE_XENPV


Why such a big ALTERNATIVE when you can simply do:

 /*
  * Try to use SYSRET instead of IRET if we're returning to
  * a completely clean 64-bit userspace context.  If we're not,
  * go to the slow exit path.
  * In the Xen PV case we must use iret anyway.
  */
 ALTERNATIVE "", "jmp swapgs_restore_regs_and_return_to_usermode", 
X86_FEATURE_XENPV

 movqRCX(%rsp), %rcx;
 movqRIP(%rsp), %r11;
 cmpq%rcx, %r11; /* SYSRET requires RCX == RIP */ \
 jne swapgs_restore_regs_and_return_to_usermode

?



I wanted to avoid the additional NOPs for the bare metal case.

If you don't mind them I can do as you are suggesting.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces


Hi

Am 02.12.20 um 15:02 schrieb Alex Deucher:

On Wed, Dec 2, 2020 at 3:53 AM Thomas Zimmermann  wrote:


Hi

Am 02.12.20 um 09:43 schrieb Christian König:

Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:

Hi

Am 01.12.20 um 11:40 schrieb Christian König:

Reviewed-by: Christian König  on patch #1
and #15.

Acked-by: Christian König  on patch #2 and
#16.


Could you add these patches to the AMD tree?


Alex is usually the one who picks such stuff up.

But when people send out patch sets which mix changes from different
drivers it is more common to push them through drm-misc-next.


I'm OK with drm-misc-next. I just don't want to add too many merge
conflicts in your side.


Yeah, it doesn't matter to me.  I assumed you wanted to land this
whole series so you could move forward with further cleanups.  If we
merge via different trees, you'll have to wait for all of this to come
together again in drm-next.


OK, sure. I'll merge it through drm-misc-next.

Best regards
Thomas



Alex




Best regards
Thomas



Regards,
Christian.



Best regards
Thomas



Regards,
Christian.

Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:

Adhere to kernel coding style.

Signed-off-by: Thomas Zimmermann 
Acked-by: Alex Deucher 
Acked-by: Sam Ravnborg 
Cc: Alex Deucher 
Cc: Christian König 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 5f304425c948..da23c0f21311 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4922,8 +4922,8 @@ pci_ers_result_t
amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta
   case pci_channel_io_normal:
   return PCI_ERS_RESULT_CAN_RECOVER;
   /* Fatal error, prepare for slot reset */
-case pci_channel_io_frozen:
-/*
+case pci_channel_io_frozen:
+/*
* Cancel and wait for all TDRs in progress if failing to
* set  adev->in_gpu_reset in amdgpu_device_lock_adev
*
@@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct
pci_dev *pdev)
   goto out;
   }
-adev->in_pci_err_recovery = true;
+adev->in_pci_err_recovery = true;
   r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset);
   adev->in_pci_err_recovery = false;
   if (r)








--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev


Hi

Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:

Hi

Am 30.11.20 um 21:59 schrieb Zack Rusin:



On Nov 24, 2020, at 06:38, Thomas Zimmermann  
wrote:


Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Roland Scheidegger 
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |  8 
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c    | 27 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-


Reviewed-by: Zack Rusin 


Could you add this patch to the vmwgfx tree?


AMD devs indicated that they'd prefer to merge the patchset trough 
drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch 
through drm-misc-next as well.


Best regards
Thomas



Best regards
Thomas



z




___
Nouveau mailing list
nouv...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces

2020-12-02 Thread Alex Deucher

On Wed, Dec 2, 2020 at 3:53 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 02.12.20 um 09:43 schrieb Christian König:
> > Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:
> >> Hi
> >>
> >> Am 01.12.20 um 11:40 schrieb Christian König:
> >>> Reviewed-by: Christian König  on patch #1
> >>> and #15.
> >>>
> >>> Acked-by: Christian König  on patch #2 and
> >>> #16.
> >>
> >> Could you add these patches to the AMD tree?
> >
> > Alex is usually the one who picks such stuff up.
> >
> > But when people send out patch sets which mix changes from different
> > drivers it is more common to push them through drm-misc-next.
>
> I'm OK with drm-misc-next. I just don't want to add too many merge
> conflicts in your side.

Yeah, it doesn't matter to me.  I assumed you wanted to land this
whole series so you could move forward with further cleanups.  If we
merge via different trees, you'll have to wait for all of this to come
together again in drm-next.

Alex


>
> Best regards
> Thomas
>
> >
> > Regards,
> > Christian.
> >
> >>
> >> Best regards
> >> Thomas
> >>
> >>>
> >>> Regards,
> >>> Christian.
> >>>
> >>> Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:
>  Adhere to kernel coding style.
> 
>  Signed-off-by: Thomas Zimmermann 
>  Acked-by: Alex Deucher 
>  Acked-by: Sam Ravnborg 
>  Cc: Alex Deucher 
>  Cc: Christian König 
>  ---
>    drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
>    1 file changed, 3 insertions(+), 3 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>  b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>  index 5f304425c948..da23c0f21311 100644
>  --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>  +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>  @@ -4922,8 +4922,8 @@ pci_ers_result_t
>  amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta
>    case pci_channel_io_normal:
>    return PCI_ERS_RESULT_CAN_RECOVER;
>    /* Fatal error, prepare for slot reset */
>  -case pci_channel_io_frozen:
>  -/*
>  +case pci_channel_io_frozen:
>  +/*
> * Cancel and wait for all TDRs in progress if failing to
> * set  adev->in_gpu_reset in amdgpu_device_lock_adev
> *
>  @@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct
>  pci_dev *pdev)
>    goto out;
>    }
>  -adev->in_pci_err_recovery = true;
>  +adev->in_pci_err_recovery = true;
>    r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset);
>    adev->in_pci_err_recovery = false;
>    if (r)
> >>>
> >>
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance

On 2020/12/2 下午5:23, Michael S. Tsirkin wrote:

On Wed, Dec 02, 2020 at 07:57:14AM +0200, Eli Cohen wrote:

On Wed, Dec 02, 2020 at 12:18:36PM +0800, Jason Wang wrote:

On 2020/12/1 下午5:23, Cindy Lu wrote:

On Mon, Nov 30, 2020 at 11:33 PM Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 06:41:45PM +0800, Cindy Lu wrote:

On Mon, Nov 30, 2020 at 5:33 PM Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 11:27:59AM +0200, Eli Cohen wrote:

On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:

On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. Tsirkin wrote:

On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen wrote:

We should not try to use the VF MAC address as that is used by the
regular (e.g. mlx5_core) NIC implementation. Instead, use a random
generated MAC address.

Suggested by: Cindy Lu
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Eli Cohen

I didn't realise it's possible to use VF in two ways
with and without vdpa.

Using a VF you can create quite a few resources, e.g. send queues
recieve queues, virtio_net queues etc. So you can possibly create
several instances of vdpa net devices and nic net devices.

Could you include a bit more description on the failure
mode?

Well, using the MAC address of the nic vport is wrong since that is the
MAC of the regular NIC implementation of mlx5_core.

Right but ATM it doesn't coexist with vdpa so what's the problem?

This call is wrong: mlx5_query_nic_vport_mac_address()

Is switching to a random mac for such an unusual
configuration really justified?

Since I can't use the NIC's MAC address, I have two options:
1. To get the MAC address as was chosen by the user administering the
NIC. This should invoke the set_config callback. Unfortunately this
is not implemented yet.

2. Use a random MAC address. This is OK since if (1) is implemented it
can always override this random configuration.

It looks like changing a MAC could break some guests,
can it not?

No, it will not. The current version of mlx5 VDPA does not allow regular
NIC driver and VDPA to co-exist. I have patches ready that enable that
from steering point of view. I will post them here once other patches on
which they depend will be merged.

https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/

Could you be more explicit on the following points:
- which configuration is broken ATM (as in, two device have identical
macs? any other issues)?

The only wrong thing is the call to mlx5_query_nic_vport_mac_address().
It's not breaking anything yet is wrong. The random MAC address setting
is required for the steering patches.

Okay so I'm not sure the Fixes tag at least is appropriate if it's a
dependency of a new feature.

- why won't device MAC change from guest point of view?

It's lack of implementation in qemu as far as I know.

Sorry not sure I understand. What's not implemented in QEMU?

HI Michael, there are some bug in qemu to set_config, this will fix in future,
But this patch is still needed, because without this patch the mlx
driver will give an 0 mac address to qemu
and qemu will overwrite the default mac address. This will cause traffic down.

Hmm the patch description says VF mac address, not 0 address. Confused.
If there's no mac we can clear VIRTIO_NET_F_MAC and have guest
use a random value ...

I'm not sure this can work for all types of vDPA (e.g it could not be a
learning bridge in the swtich).

hi Michael，
I have tried as your suggestion, seems even remove the
VIRTIO_NET_F_MAC the qemu will still call get_cinfig and overwrite the
default address in VM,

This looks a bug in qemu, in guest driver we had:

/* Configuration may specify what MAC to use. Otherwise random. */
if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC))
virtio_cread_bytes(vdev,
offsetof(struct virtio_net_config, mac),
dev->dev_addr, dev->addr_len);
else
eth_hw_addr_random(dev);

this process is like
vdpa _init -->qemu call get_config ->mlx driver will give an mac
address with all 0-->
qemu will not check this mac address and use it --> overwrite the mac
address in qemu

So for my understanding there are several method to fix this problem

1, qemu check the mac address, if the mac address is all 0, qemu will
ignore it and set the random mac address to mlx driver.

So my understanding is that, if mac address is all 0, vDPA parent should not
advertise VIRTIO_NET_F_MAC. And qemu should emulate this feature as you did:

Thinking it over, at least in mlx5, I should always advertise
VIRTIO_NET_F_MAC and set a non zero MAC value. The source of the MAC can
be either randomly generated value by mlx5_vdpa or by a management tool.
This is important becauase we should not let the VM modify the MAC. If
we do it can set a MAC value identical to the mlx5 NIC

Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance

On 2020/12/2 下午9:04, Michael S. Tsirkin wrote:

On Wed, Dec 02, 2020 at 08:56:37PM +0800, Jason Wang wrote:

On 2020/12/2 下午5:30, Michael S. Tsirkin wrote:

On Wed, Dec 02, 2020 at 12:18:36PM +0800, Jason Wang wrote:

On 2020/12/1 下午5:23, Cindy Lu wrote:

On Mon, Nov 30, 2020 at 11:33 PM Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 06:41:45PM +0800, Cindy Lu wrote:

On Mon, Nov 30, 2020 at 5:33 PM Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 11:27:59AM +0200, Eli Cohen wrote:

On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:

On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. Tsirkin wrote:

On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen wrote:

We should not try to use the VF MAC address as that is used by the
regular (e.g. mlx5_core) NIC implementation. Instead, use a random
generated MAC address.

Suggested by: Cindy Lu
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Eli Cohen

I didn't realise it's possible to use VF in two ways
with and without vdpa.

Using a VF you can create quite a few resources, e.g. send queues
recieve queues, virtio_net queues etc. So you can possibly create
several instances of vdpa net devices and nic net devices.

Could you include a bit more description on the failure
mode?

Well, using the MAC address of the nic vport is wrong since that is the
MAC of the regular NIC implementation of mlx5_core.

Right but ATM it doesn't coexist with vdpa so what's the problem?

This call is wrong: mlx5_query_nic_vport_mac_address()

Is switching to a random mac for such an unusual
configuration really justified?

2. Use a random MAC address. This is OK since if (1) is implemented it
can always override this random configuration.

It looks like changing a MAC could break some guests,
can it not?

https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/

Could you be more explicit on the following points:
- which configuration is broken ATM (as in, two device have identical
macs? any other issues)?

The only wrong thing is the call to mlx5_query_nic_vport_mac_address().
It's not breaking anything yet is wrong. The random MAC address setting
is required for the steering patches.

Okay so I'm not sure the Fixes tag at least is appropriate if it's a
dependency of a new feature.

- why won't device MAC change from guest point of view?

It's lack of implementation in qemu as far as I know.

Sorry not sure I understand. What's not implemented in QEMU?

Hmm the patch description says VF mac address, not 0 address. Confused.
If there's no mac we can clear VIRTIO_NET_F_MAC and have guest
use a random value ...

I'm not sure this can work for all types of vDPA (e.g it could not be a
learning bridge in the swtich).

hi Michael，
I have tried as your suggestion, seems even remove the
VIRTIO_NET_F_MAC the qemu will still call get_cinfig and overwrite the
default address in VM,

This looks a bug in qemu, in guest driver we had:

this process is like
vdpa _init -->qemu call get_config ->mlx driver will give an mac
address with all 0-->
qemu will not check this mac address and use it --> overwrite the mac
address in qemu

So for my understanding there are several method to fix this problem

1, qemu check the mac address, if the mac address is all 0, qemu will
ignore it and set the random mac address to mlx driver.

So my understanding is that, if mac address is all 0, vDPA parent should not
advertise VIRTIO_NET_F_MAC. And qemu should emulate this feature as you did:

1) get a random mac

To me this looks like a spec violation.

If the driver negotiates the VIRTIO_NET_F_MAC feature, the driver MUST set
the physical address of the NIC to \field{mac}. Otherwise, it SHOULD
use a locally-administered MAC address (see \hyperref[intro:IEEE

Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance



On 2020/12/2 下午9:07, Michael S. Tsirkin wrote:

Two questions here:
1. Now we don't have support for control virtqueue. Yet, we must filter
packets based on MAC, what do you suggest to do here?

How about an ioctl to pass the mac to the device?
Maybe mirroring the control vq struct format ...

I think we'd better avoid such ad-hoc ioctls to make vhost-vDPA type
independent.

Fundamentally this is about handling some VQs in QEMU, right?
Maybe a generic ioctl along the lines of "CTRL_VQ" passing
vq number and a command buffer from guest?
Seems generic enough for you?



It looks to me you want to invent a synchronized API (or vDPA config 
ops) for submitting virtio descriptors.


Several issues I can think for this:

1) control vq allows the request to be handled asynchronously
2) we still need a way to isolate the DMA if there's a hardware 
virtqueue for the device that use DMA
3) new vDPA config operations need to be invented, new uAPI for 
vhost-vDPA, new virtio config ops for virtio-vDPA


It looks to me we can overcome 1) and 2) if we just stick to a virtqueue 
interface in vhost-vDPA as I proposed in [1]. For issue 3) it also 
requires much less work.


Thanks

[1] https://lkml.org/lkml/2020/9/23/1243

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance

On Wed, Dec 02, 2020 at 09:00:07PM +0800, Jason Wang wrote:
> 
> On 2020/12/2 下午8:17, Michael S. Tsirkin wrote:
> > On Wed, Dec 02, 2020 at 02:12:41PM +0200, Eli Cohen wrote:
> > > On Wed, Dec 02, 2020 at 04:23:11AM -0500, Michael S. Tsirkin wrote:
> > > > On Wed, Dec 02, 2020 at 07:57:14AM +0200, Eli Cohen wrote:
> > > > > On Wed, Dec 02, 2020 at 12:18:36PM +0800, Jason Wang wrote:
> > > > > > On 2020/12/1 下午5:23, Cindy Lu wrote:
> > > > > > > On Mon, Nov 30, 2020 at 11:33 PM Michael S. 
> > > > > > > Tsirkin  wrote:
> > > > > > > > On Mon, Nov 30, 2020 at 06:41:45PM +0800, Cindy Lu wrote:
> > > > > > > > > On Mon, Nov 30, 2020 at 5:33 PM Michael S. 
> > > > > > > > > Tsirkin  wrote:
> > > > > > > > > > On Mon, Nov 30, 2020 at 11:27:59AM +0200, Eli Cohen wrote:
> > > > > > > > > > > On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. 
> > > > > > > > > > > Tsirkin wrote:
> > > > > > > > > > > > On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. 
> > > > > > > > > > > > > Tsirkin wrote:
> > > > > > > > > > > > > > On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen 
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > We should not try to use the VF MAC address as 
> > > > > > > > > > > > > > > that is used by the
> > > > > > > > > > > > > > > regular (e.g. mlx5_core) NIC implementation. 
> > > > > > > > > > > > > > > Instead, use a random
> > > > > > > > > > > > > > > generated MAC address.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Suggested by: Cindy Lu
> > > > > > > > > > > > > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver 
> > > > > > > > > > > > > > > for supported mlx5 devices")
> > > > > > > > > > > > > > > Signed-off-by: Eli Cohen
> > > > > > > > > > > > > > I didn't realise it's possible to use VF in two ways
> > > > > > > > > > > > > > with and without vdpa.
> > > > > > > > > > > > > Using a VF you can create quite a few resources, e.g. 
> > > > > > > > > > > > > send queues
> > > > > > > > > > > > > recieve queues, virtio_net queues etc. So you can 
> > > > > > > > > > > > > possibly create
> > > > > > > > > > > > > several instances of vdpa net devices and nic net 
> > > > > > > > > > > > > devices.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > Could you include a bit more description on the 
> > > > > > > > > > > > > > failure
> > > > > > > > > > > > > > mode?
> > > > > > > > > > > > > Well, using the MAC address of the nic vport is wrong 
> > > > > > > > > > > > > since that is the
> > > > > > > > > > > > > MAC of the regular NIC implementation of mlx5_core.
> > > > > > > > > > > > Right but ATM it doesn't coexist with vdpa so what's 
> > > > > > > > > > > > the problem?
> > > > > > > > > > > > 
> > > > > > > > > > > This call is wrong:  mlx5_query_nic_vport_mac_address()
> > > > > > > > > > > 
> > > > > > > > > > > > > > Is switching to a random mac for such an unusual
> > > > > > > > > > > > > > configuration really justified?
> > > > > > > > > > > > > Since I can't use the NIC's MAC address, I have two 
> > > > > > > > > > > > > options:
> > > > > > > > > > > > > 1. To get the MAC address as was chosen by the user 
> > > > > > > > > > > > > administering the
> > > > > > > > > > > > >  NIC. This should invoke the set_config callback. 
> > > > > > > > > > > > > Unfortunately this
> > > > > > > > > > > > >  is not implemented yet.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 2. Use a random MAC address. This is OK since if (1) 
> > > > > > > > > > > > > is implemented it
> > > > > > > > > > > > >  can always override this random configuration.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > It looks like changing a MAC could break some 
> > > > > > > > > > > > > > guests,
> > > > > > > > > > > > > > can it not?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > No, it will not. The current version of mlx5 VDPA 
> > > > > > > > > > > > > does not allow regular
> > > > > > > > > > > > > NIC driver and VDPA to co-exist. I have patches ready 
> > > > > > > > > > > > > that enable that
> > > > > > > > > > > > > from steering point of view. I will post them here 
> > > > > > > > > > > > > once other patches on
> > > > > > > > > > > > > which they depend will be merged.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/
> > > > > > > > > > > > Could you be more explicit on the following points:
> > > > > > > > > > > > - which configuration is broken ATM (as in, two device 
> > > > > > > > > > > > have identical
> > > > > > > > > > > > macs? any other issues)?
> > > > > > > > > > > The only wrong thing is the call to  
> > > > > > > > > > > mlx5_query_nic_vport_mac_address().
> > > > > > > > > > > It's not breaking anything yet is wrong. The random MAC 
> > > > > > > > > > > address setting
> > > > > > > > > > >

Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance

On Wed, Dec 02, 2020 at 08:56:37PM +0800, Jason Wang wrote:
> 
> On 2020/12/2 下午5:30, Michael S. Tsirkin wrote:
> > On Wed, Dec 02, 2020 at 12:18:36PM +0800, Jason Wang wrote:
> > > On 2020/12/1 下午5:23, Cindy Lu wrote:
> > > > On Mon, Nov 30, 2020 at 11:33 PM Michael S. Tsirkin  
> > > > wrote:
> > > > > On Mon, Nov 30, 2020 at 06:41:45PM +0800, Cindy Lu wrote:
> > > > > > On Mon, Nov 30, 2020 at 5:33 PM Michael S. Tsirkin 
> > > > > >  wrote:
> > > > > > > On Mon, Nov 30, 2020 at 11:27:59AM +0200, Eli Cohen wrote:
> > > > > > > > On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. Tsirkin 
> > > > > > > > wrote:
> > > > > > > > > On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:
> > > > > > > > > > On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. 
> > > > > > > > > > Tsirkin wrote:
> > > > > > > > > > > On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen wrote:
> > > > > > > > > > > > We should not try to use the VF MAC address as that is 
> > > > > > > > > > > > used by the
> > > > > > > > > > > > regular (e.g. mlx5_core) NIC implementation. Instead, 
> > > > > > > > > > > > use a random
> > > > > > > > > > > > generated MAC address.
> > > > > > > > > > > > 
> > > > > > > > > > > > Suggested by: Cindy Lu 
> > > > > > > > > > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for 
> > > > > > > > > > > > supported mlx5 devices")
> > > > > > > > > > > > Signed-off-by: Eli Cohen 
> > > > > > > > > > > I didn't realise it's possible to use VF in two ways
> > > > > > > > > > > with and without vdpa.
> > > > > > > > > > Using a VF you can create quite a few resources, e.g. send 
> > > > > > > > > > queues
> > > > > > > > > > recieve queues, virtio_net queues etc. So you can possibly 
> > > > > > > > > > create
> > > > > > > > > > several instances of vdpa net devices and nic net devices.
> > > > > > > > > > 
> > > > > > > > > > > Could you include a bit more description on the failure
> > > > > > > > > > > mode?
> > > > > > > > > > Well, using the MAC address of the nic vport is wrong since 
> > > > > > > > > > that is the
> > > > > > > > > > MAC of the regular NIC implementation of mlx5_core.
> > > > > > > > > Right but ATM it doesn't coexist with vdpa so what's the 
> > > > > > > > > problem?
> > > > > > > > > 
> > > > > > > > This call is wrong:  mlx5_query_nic_vport_mac_address()
> > > > > > > > 
> > > > > > > > > > > Is switching to a random mac for such an unusual
> > > > > > > > > > > configuration really justified?
> > > > > > > > > > Since I can't use the NIC's MAC address, I have two options:
> > > > > > > > > > 1. To get the MAC address as was chosen by the user 
> > > > > > > > > > administering the
> > > > > > > > > >  NIC. This should invoke the set_config callback. 
> > > > > > > > > > Unfortunately this
> > > > > > > > > >  is not implemented yet.
> > > > > > > > > > 
> > > > > > > > > > 2. Use a random MAC address. This is OK since if (1) is 
> > > > > > > > > > implemented it
> > > > > > > > > >  can always override this random configuration.
> > > > > > > > > > 
> > > > > > > > > > > It looks like changing a MAC could break some guests,
> > > > > > > > > > > can it not?
> > > > > > > > > > > 
> > > > > > > > > > No, it will not. The current version of mlx5 VDPA does not 
> > > > > > > > > > allow regular
> > > > > > > > > > NIC driver and VDPA to co-exist. I have patches ready that 
> > > > > > > > > > enable that
> > > > > > > > > > from steering point of view. I will post them here once 
> > > > > > > > > > other patches on
> > > > > > > > > > which they depend will be merged.
> > > > > > > > > > 
> > > > > > > > > > https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/
> > > > > > > > > Could you be more explicit on the following points:
> > > > > > > > > - which configuration is broken ATM (as in, two device have 
> > > > > > > > > identical
> > > > > > > > > macs? any other issues)?
> > > > > > > > The only wrong thing is the call to  
> > > > > > > > mlx5_query_nic_vport_mac_address().
> > > > > > > > It's not breaking anything yet is wrong. The random MAC address 
> > > > > > > > setting
> > > > > > > > is required for the steering patches.
> > > > > > > Okay so I'm not sure the Fixes tag at least is appropriate if 
> > > > > > > it's a
> > > > > > > dependency of a new feature.
> > > > > > > 
> > > > > > > > > - why won't device MAC change from guest point of view?
> > > > > > > > > 
> > > > > > > > It's lack of implementation in qemu as far as I know.
> > > > > > > Sorry not sure I understand. What's not implemented in QEMU?
> > > > > > > 
> > > > > > HI Michael, there are some bug in qemu to set_config, this will fix 
> > > > > > in future,
> > > > > > But this patch is still needed, because without this patch the mlx
> > > > > > driver will give an 0 mac address to qemu
> > > > > > and qemu will overwrite the default mac address.  This will cause 
> > > > > > traffic down.
> > > > > Hmm the patch description

Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance

On 2020/12/2 下午8:17, Michael S. Tsirkin wrote:

On Wed, Dec 02, 2020 at 02:12:41PM +0200, Eli Cohen wrote:

On Wed, Dec 02, 2020 at 04:23:11AM -0500, Michael S. Tsirkin wrote:

On Wed, Dec 02, 2020 at 07:57:14AM +0200, Eli Cohen wrote:

On Wed, Dec 02, 2020 at 12:18:36PM +0800, Jason Wang wrote:

On 2020/12/1 下午5:23, Cindy Lu wrote:

On Mon, Nov 30, 2020 at 11:33 PM Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 06:41:45PM +0800, Cindy Lu wrote:

On Mon, Nov 30, 2020 at 5:33 PM Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 11:27:59AM +0200, Eli Cohen wrote:

On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:

On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. Tsirkin wrote:

On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen wrote:

We should not try to use the VF MAC address as that is used by the
regular (e.g. mlx5_core) NIC implementation. Instead, use a random
generated MAC address.

Suggested by: Cindy Lu
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Eli Cohen

I didn't realise it's possible to use VF in two ways
with and without vdpa.

Using a VF you can create quite a few resources, e.g. send queues
recieve queues, virtio_net queues etc. So you can possibly create
several instances of vdpa net devices and nic net devices.

Could you include a bit more description on the failure
mode?

Well, using the MAC address of the nic vport is wrong since that is the
MAC of the regular NIC implementation of mlx5_core.

Right but ATM it doesn't coexist with vdpa so what's the problem?

This call is wrong: mlx5_query_nic_vport_mac_address()

Is switching to a random mac for such an unusual
configuration really justified?

2. Use a random MAC address. This is OK since if (1) is implemented it
can always override this random configuration.

It looks like changing a MAC could break some guests,
can it not?

https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/

Could you be more explicit on the following points:
- which configuration is broken ATM (as in, two device have identical
macs? any other issues)?

The only wrong thing is the call to mlx5_query_nic_vport_mac_address().
It's not breaking anything yet is wrong. The random MAC address setting
is required for the steering patches.

Okay so I'm not sure the Fixes tag at least is appropriate if it's a
dependency of a new feature.

- why won't device MAC change from guest point of view?

It's lack of implementation in qemu as far as I know.

Sorry not sure I understand. What's not implemented in QEMU?

Hmm the patch description says VF mac address, not 0 address. Confused.
If there's no mac we can clear VIRTIO_NET_F_MAC and have guest
use a random value ...

I'm not sure this can work for all types of vDPA (e.g it could not be a
learning bridge in the swtich).

hi Michael，
I have tried as your suggestion, seems even remove the
VIRTIO_NET_F_MAC the qemu will still call get_cinfig and overwrite the
default address in VM,

This looks a bug in qemu, in guest driver we had:

this process is like
vdpa _init -->qemu call get_config ->mlx driver will give an mac
address with all 0-->
qemu will not check this mac address and use it --> overwrite the mac
address in qemu

So for my understanding there are several method to fix this problem

1, qemu check the mac address, if the mac address is all 0, qemu will
ignore it and set the random mac address to mlx driver.

So my understanding is that, if mac address is all 0, vDPA parent should not
advertise VIRTIO_NET_F_MAC. And qemu should emulate this feature as you did:

Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance

On 2020/12/2 下午5:30, Michael S. Tsirkin wrote:

On Wed, Dec 02, 2020 at 12:18:36PM +0800, Jason Wang wrote:

On 2020/12/1 下午5:23, Cindy Lu wrote:

On Mon, Nov 30, 2020 at 11:33 PM Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 06:41:45PM +0800, Cindy Lu wrote:

On Mon, Nov 30, 2020 at 5:33 PM Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 11:27:59AM +0200, Eli Cohen wrote:

On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. Tsirkin wrote:

On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:

On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. Tsirkin wrote:

On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen wrote:

We should not try to use the VF MAC address as that is used by the
regular (e.g. mlx5_core) NIC implementation. Instead, use a random
generated MAC address.

Suggested by: Cindy Lu
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Eli Cohen

I didn't realise it's possible to use VF in two ways
with and without vdpa.

Using a VF you can create quite a few resources, e.g. send queues
recieve queues, virtio_net queues etc. So you can possibly create
several instances of vdpa net devices and nic net devices.

Could you include a bit more description on the failure
mode?

Well, using the MAC address of the nic vport is wrong since that is the
MAC of the regular NIC implementation of mlx5_core.

Right but ATM it doesn't coexist with vdpa so what's the problem?

This call is wrong: mlx5_query_nic_vport_mac_address()

Is switching to a random mac for such an unusual
configuration really justified?

2. Use a random MAC address. This is OK since if (1) is implemented it
can always override this random configuration.

It looks like changing a MAC could break some guests,
can it not?

https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/

Could you be more explicit on the following points:
- which configuration is broken ATM (as in, two device have identical
macs? any other issues)?

The only wrong thing is the call to mlx5_query_nic_vport_mac_address().
It's not breaking anything yet is wrong. The random MAC address setting
is required for the steering patches.

Okay so I'm not sure the Fixes tag at least is appropriate if it's a
dependency of a new feature.

- why won't device MAC change from guest point of view?

It's lack of implementation in qemu as far as I know.

Sorry not sure I understand. What's not implemented in QEMU?

Hmm the patch description says VF mac address, not 0 address. Confused.
If there's no mac we can clear VIRTIO_NET_F_MAC and have guest
use a random value ...

I'm not sure this can work for all types of vDPA (e.g it could not be a
learning bridge in the swtich).

hi Michael，
I have tried as your suggestion, seems even remove the
VIRTIO_NET_F_MAC the qemu will still call get_cinfig and overwrite the
default address in VM,

This looks a bug in qemu, in guest driver we had:

this process is like
vdpa _init -->qemu call get_config ->mlx driver will give an mac
address with all 0-->
qemu will not check this mac address and use it --> overwrite the mac
address in qemu

So for my understanding there are several method to fix this problem

1, qemu check the mac address, if the mac address is all 0, qemu will
ignore it and set the random mac address to mlx driver.

So my understanding is that, if mac address is all 0, vDPA parent should not
advertise VIRTIO_NET_F_MAC. And qemu should emulate this feature as you did:

1) get a random mac

To me this looks like a spec violation.

One question here, what did "set" mean here consider the

Re: [PATCH v2 04/12] x86/xen: drop USERGS_SYSRET64 paravirt call

2020-12-02 Thread Borislav Petkov

On Fri, Nov 20, 2020 at 12:46:22PM +0100, Juergen Gross wrote:
> @@ -123,12 +115,15 @@ SYM_INNER_LABEL(entry_SYSCALL_64_after_hwframe, 
> SYM_L_GLOBAL)
>* Try to use SYSRET instead of IRET if we're returning to
>* a completely clean 64-bit userspace context.  If we're not,
>* go to the slow exit path.
> +  * In the Xen PV case we must use iret anyway.
>*/
> - movqRCX(%rsp), %rcx
> - movqRIP(%rsp), %r11
>  
> - cmpq%rcx, %r11  /* SYSRET requires RCX == RIP */
> - jne swapgs_restore_regs_and_return_to_usermode
> + ALTERNATIVE __stringify( \
> + movqRCX(%rsp), %rcx; \
> + movqRIP(%rsp), %r11; \
> + cmpq%rcx, %r11; /* SYSRET requires RCX == RIP */ \
> + jne swapgs_restore_regs_and_return_to_usermode), \
> + "jmpswapgs_restore_regs_and_return_to_usermode", X86_FEATURE_XENPV

Why such a big ALTERNATIVE when you can simply do:

/*
 * Try to use SYSRET instead of IRET if we're returning to
 * a completely clean 64-bit userspace context.  If we're not,
 * go to the slow exit path.
 * In the Xen PV case we must use iret anyway.
 */
ALTERNATIVE "", "jmp swapgs_restore_regs_and_return_to_usermode", 
X86_FEATURE_XENPV

movqRCX(%rsp), %rcx;
movqRIP(%rsp), %r11;
cmpq%rcx, %r11; /* SYSRET requires RCX == RIP */ \
jne swapgs_restore_regs_and_return_to_usermode

?

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance

On Wed, Dec 02, 2020 at 02:12:41PM +0200, Eli Cohen wrote:
> On Wed, Dec 02, 2020 at 04:23:11AM -0500, Michael S. Tsirkin wrote:
> > On Wed, Dec 02, 2020 at 07:57:14AM +0200, Eli Cohen wrote:
> > > On Wed, Dec 02, 2020 at 12:18:36PM +0800, Jason Wang wrote:
> > > > 
> > > > On 2020/12/1 下午5:23, Cindy Lu wrote:
> > > > > On Mon, Nov 30, 2020 at 11:33 PM Michael S. Tsirkin  
> > > > > wrote:
> > > > > > On Mon, Nov 30, 2020 at 06:41:45PM +0800, Cindy Lu wrote:
> > > > > > > On Mon, Nov 30, 2020 at 5:33 PM Michael S. Tsirkin 
> > > > > > >  wrote:
> > > > > > > > On Mon, Nov 30, 2020 at 11:27:59AM +0200, Eli Cohen wrote:
> > > > > > > > > On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. Tsirkin 
> > > > > > > > > wrote:
> > > > > > > > > > On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:
> > > > > > > > > > > On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. 
> > > > > > > > > > > Tsirkin wrote:
> > > > > > > > > > > > On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > We should not try to use the VF MAC address as that 
> > > > > > > > > > > > > is used by the
> > > > > > > > > > > > > regular (e.g. mlx5_core) NIC implementation. Instead, 
> > > > > > > > > > > > > use a random
> > > > > > > > > > > > > generated MAC address.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Suggested by: Cindy Lu 
> > > > > > > > > > > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for 
> > > > > > > > > > > > > supported mlx5 devices")
> > > > > > > > > > > > > Signed-off-by: Eli Cohen 
> > > > > > > > > > > > I didn't realise it's possible to use VF in two ways
> > > > > > > > > > > > with and without vdpa.
> > > > > > > > > > > Using a VF you can create quite a few resources, e.g. 
> > > > > > > > > > > send queues
> > > > > > > > > > > recieve queues, virtio_net queues etc. So you can 
> > > > > > > > > > > possibly create
> > > > > > > > > > > several instances of vdpa net devices and nic net devices.
> > > > > > > > > > > 
> > > > > > > > > > > > Could you include a bit more description on the failure
> > > > > > > > > > > > mode?
> > > > > > > > > > > Well, using the MAC address of the nic vport is wrong 
> > > > > > > > > > > since that is the
> > > > > > > > > > > MAC of the regular NIC implementation of mlx5_core.
> > > > > > > > > > Right but ATM it doesn't coexist with vdpa so what's the 
> > > > > > > > > > problem?
> > > > > > > > > > 
> > > > > > > > > This call is wrong:  mlx5_query_nic_vport_mac_address()
> > > > > > > > > 
> > > > > > > > > > > > Is switching to a random mac for such an unusual
> > > > > > > > > > > > configuration really justified?
> > > > > > > > > > > Since I can't use the NIC's MAC address, I have two 
> > > > > > > > > > > options:
> > > > > > > > > > > 1. To get the MAC address as was chosen by the user 
> > > > > > > > > > > administering the
> > > > > > > > > > > NIC. This should invoke the set_config callback. 
> > > > > > > > > > > Unfortunately this
> > > > > > > > > > > is not implemented yet.
> > > > > > > > > > > 
> > > > > > > > > > > 2. Use a random MAC address. This is OK since if (1) is 
> > > > > > > > > > > implemented it
> > > > > > > > > > > can always override this random configuration.
> > > > > > > > > > > 
> > > > > > > > > > > > It looks like changing a MAC could break some guests,
> > > > > > > > > > > > can it not?
> > > > > > > > > > > > 
> > > > > > > > > > > No, it will not. The current version of mlx5 VDPA does 
> > > > > > > > > > > not allow regular
> > > > > > > > > > > NIC driver and VDPA to co-exist. I have patches ready 
> > > > > > > > > > > that enable that
> > > > > > > > > > > from steering point of view. I will post them here once 
> > > > > > > > > > > other patches on
> > > > > > > > > > > which they depend will be merged.
> > > > > > > > > > > 
> > > > > > > > > > > https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/
> > > > > > > > > > Could you be more explicit on the following points:
> > > > > > > > > > - which configuration is broken ATM (as in, two device have 
> > > > > > > > > > identical
> > > > > > > > > >macs? any other issues)?
> > > > > > > > > The only wrong thing is the call to  
> > > > > > > > > mlx5_query_nic_vport_mac_address().
> > > > > > > > > It's not breaking anything yet is wrong. The random MAC 
> > > > > > > > > address setting
> > > > > > > > > is required for the steering patches.
> > > > > > > > Okay so I'm not sure the Fixes tag at least is appropriate if 
> > > > > > > > it's a
> > > > > > > > dependency of a new feature.
> > > > > > > > 
> > > > > > > > > > - why won't device MAC change from guest point of view?
> > > > > > > > > > 
> > > > > > > > > It's lack of implementation in qemu as far as I know.
> > > > > > > > Sorry not sure I understand. What's not implemented in QEMU?
> > > > > > > > 
> > > > > > > HI Michael, there are some bug in qemu to set_config, this

[GIT PULL] vdpa: last minute bugfixes

A couple of patches of the obviously correct variety.

The following changes since commit ad89653f79f1882d55d9df76c9b2b94f008c4e27:

  vhost-vdpa: fix page pinning leakage in error path (rework) (2020-11-25 
04:29:07 -0500)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus

for you to fetch changes up to 2c602741b51daa12f8457f222ce9ce9c4825d067:

  vhost_vdpa: return -EFAULT if copy_to_user() fails (2020-12-02 04:36:40 -0500)


vdpa: last minute bugfixes

A couple of fixes that surfaced at the last minute.

Signed-off-by: Michael S. Tsirkin 


Dan Carpenter (1):
  vhost_vdpa: return -EFAULT if copy_to_user() fails

Randy Dunlap (1):
  vdpa: mlx5: fix vdpa/vhost dependencies

 drivers/Makefile | 1 +
 drivers/vdpa/Kconfig | 1 +
 drivers/vhost/vdpa.c | 4 +++-
 3 files changed, 5 insertions(+), 1 deletion(-)

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 2/2] uapi: virtio_ids: add missing device type IDs from OASIS spec

On Wed, Dec 02, 2020 at 12:19:31PM +0100, Enrico Weigelt, metux IT consult 
wrote:
> The OASIS virtio spec (1.1) defines several IDs that aren't reflected
> in the header yet. Fixing this by adding the missing IDs, even though
> they're not yet used by the kernel yet.


double yet ;)

> 
> Signed-off-by: Enrico Weigelt, metux IT consult 
> ---
>  include/uapi/linux/virtio_ids.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/uapi/linux/virtio_ids.h b/include/uapi/linux/virtio_ids.h
> index 3cb55e5277a1..bc1c0621f5ed 100644
> --- a/include/uapi/linux/virtio_ids.h
> +++ b/include/uapi/linux/virtio_ids.h
> @@ -34,15 +34,21 @@
>  #define VIRTIO_ID_CONSOLE3 /* virtio console */
>  #define VIRTIO_ID_RNG4 /* virtio rng */
>  #define VIRTIO_ID_BALLOON5 /* virtio balloon */
> +#define VIRTIO_ID_IOMEM  6 /* virtio ioMemory */
>  #define VIRTIO_ID_RPMSG  7 /* virtio remote processor 
> messaging */
>  #define VIRTIO_ID_SCSI   8 /* virtio scsi */
>  #define VIRTIO_ID_9P 9 /* 9p virtio console */
> +#define VIRTIO_ID_MAC80211_WLAN  10 /* virtio WLAN MAC */
>  #define VIRTIO_ID_RPROC_SERIAL   11 /* virtio remoteproc serial 
> link */
>  #define VIRTIO_ID_CAIF   12 /* Virtio caif */
> +#define VIRTIO_ID_MEMORY_BALLOON 13 /* virtio memory balloon */
>  #define VIRTIO_ID_GPU16 /* virtio GPU */
> +#define VIRTIO_ID_CLOCK  17 /* virtio clock/timer */
>  #define VIRTIO_ID_INPUT  18 /* virtio input */
>  #define VIRTIO_ID_VSOCK  19 /* virtio vsock transport */
>  #define VIRTIO_ID_CRYPTO 20 /* virtio crypto */
> +#define VIRTIO_ID_SIGNAL_DIST21 /* virtio signal 
> distribution device */
> +#define VIRTIO_ID_PSTORE 22 /* virtio pstore device */
>  #define VIRTIO_ID_IOMMU  23 /* virtio IOMMU */
>  #define VIRTIO_ID_MEM24 /* virtio mem */
>  #define VIRTIO_ID_FS 26 /* virtio filesystem */
> -- 
> 2.11.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

RE: [External] Re: [PATCH 0/7] Introduce vdpa management tool

2020-12-02 Thread Parav Pandit



> From: Yongji Xie 
> Sent: Wednesday, December 2, 2020 2:52 PM
> 
> On Wed, Dec 2, 2020 at 12:53 PM Parav Pandit  wrote:
> >
> >
> >
> > > From: Yongji Xie 
> > > Sent: Wednesday, December 2, 2020 9:00 AM
> > >
> > > On Tue, Dec 1, 2020 at 11:59 PM Parav Pandit  wrote:
> > > >
> > > >
> > > >
> > > > > From: Yongji Xie 
> > > > > Sent: Tuesday, December 1, 2020 7:49 PM
> > > > >
> > > > > On Tue, Dec 1, 2020 at 7:32 PM Parav Pandit 
> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > From: Yongji Xie 
> > > > > > > Sent: Tuesday, December 1, 2020 3:26 PM
> > > > > > >
> > > > > > > On Tue, Dec 1, 2020 at 2:25 PM Jason Wang
> > > > > > > 
> > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On 2020/11/30 下午3:07, Yongji Xie wrote:
> > > > > > > > >>> Thanks for adding me, Jason!
> > > > > > > > >>>
> > > > > > > > >>> Now I'm working on a v2 patchset for VDUSE (vDPA
> > > > > > > > >>> Device in
> > > > > > > > >>> Userspace) [1]. This tool is very useful for the vduse 
> > > > > > > > >>> device.
> > > > > > > > >>> So I'm considering integrating this into my v2 patchset.
> > > > > > > > >>> But there is one problem：
> > > > > > > > >>>
> > > > > > > > >>> In this tool, vdpa device config action and enable
> > > > > > > > >>> action are combined into one netlink msg:
> > > > > > > > >>> VDPA_CMD_DEV_NEW. But in
> > > > > vduse
> > > > > > > > >>> case, it needs to be splitted because a chardev should
> > > > > > > > >>> be created and opened by a userspace process before we
> > > > > > > > >>> enable the vdpa device (call vdpa_register_device()).
> > > > > > > > >>>
> > > > > > > > >>> So I'd like to know whether it's possible (or have
> > > > > > > > >>> some
> > > > > > > > >>> plans) to add two new netlink msgs something like:
> > > > > > > > >>> VDPA_CMD_DEV_ENABLE
> > > > > > > and
> > > > > > > > >>> VDPA_CMD_DEV_DISABLE to make the config path more
> flexible.
> > > > > > > > >>>
> > > > > > > > >> Actually, we've discussed such intermediate step in
> > > > > > > > >> some early discussion. It looks to me VDUSE could be
> > > > > > > > >> one of the users of
> > > this.
> > > > > > > > >>
> > > > > > > > >> Or I wonder whether we can switch to use anonymous
> > > > > > > > >> inode(fd) for VDUSE then fetching it via an
> > > > > > > > >> VDUSE_GET_DEVICE_FD
> > > ioctl?
> > > > > > > > >>
> > > > > > > > > Yes, we can. Actually the current implementation in
> > > > > > > > > VDUSE is like this.  But seems like this is still a 
> > > > > > > > > intermediate
> step.
> > > > > > > > > The fd should be binded to a name or something else
> > > > > > > > > which need to be configured before.
> > > > > > > >
> > > > > > > >
> > > > > > > > The name could be specified via the netlink. It looks to
> > > > > > > > me the real issue is that until the device is connected
> > > > > > > > with a userspace, it can't be used. So we also need to
> > > > > > > > fail the enabling if it doesn't
> > > > > opened.
> > > > > > > >
> > > > > > >
> > > > > > > Yes, that's true. So you mean we can firstly try to fetch
> > > > > > > the fd binded to a name/vduse_id via an VDUSE_GET_DEVICE_FD,
> > > > > > > then use the name/vduse_id as a attribute to create vdpa
> > > > > > > device? It looks fine to
> > > me.
> > > > > >
> > > > > > I probably do not well understand. I tried reading patch [1]
> > > > > > and few things
> > > > > do not look correct as below.
> > > > > > Creating the vdpa device on the bus device and destroying the
> > > > > > device from
> > > > > the workqueue seems unnecessary and racy.
> > > > > >
> > > > > > It seems vduse driver needs
> > > > > > This is something should be done as part of the vdpa dev add
> > > > > > command,
> > > > > instead of connecting two sides separately and ensuring race
> > > > > free access to it.
> > > > > >
> > > > > > So VDUSE_DEV_START and VDUSE_DEV_STOP should possibly be
> avoided.
> > > > > >
> > > > >
> > > > > Yes, we can avoid these two ioctls with the help of the management
> tool.
> > > > >
> > > > > > $ vdpa dev add parentdev vduse_mgmtdev type net name foo2
> > > > > >
> > > > > > When above command is executed it creates necessary vdpa
> > > > > > device
> > > > > > foo2
> > > > > on the bus.
> > > > > > When user binds foo2 device with the vduse driver, in the
> > > > > > probe(), it
> > > > > creates respective char device to access it from user space.
> > > > >
> > > > I see. So vduse cannot work with any existing vdpa devices like
> > > > ifc, mlx5 or
> > > netdevsim.
> > > > It has its own implementation similar to fuse with its own backend of
> choice.
> > > > More below.
> > > >
> > > > > But vduse driver is not a vdpa bus driver. It works like vdpasim
> > > > > driver, but offloads the data plane and control plane to a user space
> process.
> > > >
> > > > In that case to draw parallel lines,
> > > >
> > > > 1. netdevsim:
> > > > (a) create resources in kernel sw
> > > > (b) datapath simulates in kernel
> > > >
> > > > 2. ifc +

Re: [PATCH 00/10] vhost/qemu: thread per IO SCSI vq

2020-12-02 Thread Stefano Garzarella


On Tue, Dec 01, 2020 at 05:43:38PM +, Stefan Hajnoczi wrote:

On Tue, Dec 01, 2020 at 02:45:18PM +0100, Stefano Garzarella wrote:

On Tue, Dec 01, 2020 at 12:59:43PM +, Stefan Hajnoczi wrote:
> On Fri, Nov 20, 2020 at 07:31:08AM -0500, Michael S. Tsirkin wrote:
> > On Fri, Nov 20, 2020 at 08:45:49AM +, Stefan Hajnoczi wrote:
> > > On Thu, Nov 19, 2020 at 5:08 PM Stefan Hajnoczi  
wrote:
> > > >
> > > > On Thu, Nov 19, 2020 at 4:43 PM Mike Christie
> > > >  wrote:
> > > > >
> > > > > On 11/19/20 10:24 AM, Stefan Hajnoczi wrote:
> > > > > > On Thu, Nov 19, 2020 at 4:13 PM Mike Christie
> > > > > >  wrote:
> > > > > >>
> > > > > >> On 11/19/20 8:46 AM, Michael S. Tsirkin wrote:
> > > > > >>> On Wed, Nov 18, 2020 at 11:31:17AM +, Stefan Hajnoczi wrote:
> > > > > > struct vhost_run_worker_info {
> > > > > >  struct timespec *timeout;
> > > > > >  sigset_t *sigmask;
> > > > > >
> > > > > >  /* List of virtqueues to process */
> > > > > >  unsigned nvqs;
> > > > > >  unsigned vqs[];
> > > > > > };
> > > > > >
> > > > > > /* This blocks until the timeout is reached, a signal is received, 
or
> > > > > > the vhost device is destroyed */
> > > > > > int ret = ioctl(vhost_fd, VHOST_RUN_WORKER, );
> > > > > >
> > > > > > As you can see, userspace isn't involved with dealing with the
> > > > > > requests. It just acts as a thread donor to the vhost driver.
> > > > > >
> > > > > > We would want the VHOST_RUN_WORKER calls to be infrequent to avoid 
the
> > > > > > penalty of switching into the kernel, copying in the arguments, etc.
> > > > >
> > > > > I didn't get this part. Why have the timeout? When the timeout 
expires,
> > > > > does userspace just call right back down to the kernel or does it do
> > > > > some sort of processing/operation?
> > > > >
> > > > > You could have your worker function run from that ioctl wait for a
> > > > > signal or a wake up call from the vhost_work/poll functions.
> > > >
> > > > An optional timeout argument is common in blocking interfaces like
> > > > poll(2), recvmmsg(2), etc.
> > > >
> > > > Although something can send a signal to the thread instead,
> > > > implementing that in an application is more awkward than passing a
> > > > struct timespec.
> > > >
> > > > Compared to other blocking calls we don't expect
> > > > ioctl(VHOST_RUN_WORKER) to return soon, so maybe the timeout will
> > > > rarely be used and can be dropped from the interface.
> > > >
> > > > BTW the code I posted wasn't a carefully thought out proposal 
> > > > :). The

> > > > details still need to be considered and I'm going to be offline for
> > > > the next week so maybe someone else can think it through in the
> > > > meantime.
> > >
> > > One final thought before I'm offline for a week. If
> > > ioctl(VHOST_RUN_WORKER) is specific to a single vhost device instance
> > > then it's hard to support poll-mode (busy waiting) workers because
> > > each device instance consumes a whole CPU. If we stick to an interface
> > > where the kernel manages the worker threads then it's easier to 
> > > share

> > > workers between devices for polling.
> >
> >
> > Yes that is the reason vhost did its own reason in the first place.
> >
> >
> > I am vaguely thinking about poll(2) or a similar interface,
> > which can wait for an event on multiple FDs.
>
> I can imagine how using poll(2) would work from a userspace perspective,
> but on the kernel side I don't think it can be implemented cleanly.
> poll(2) is tied to the file_operations->poll() callback and
> read/write/error events. Not to mention there isn't a way to substitue
> the vhost worker thread function instead of scheduling out the current
> thread while waiting for poll fd events.
>
> But maybe ioctl(VHOST_WORKER_RUN) can do it:
>
>  struct vhost_run_worker_dev {
>  int vhostfd;  /* /dev/vhost-TYPE fd */
>  unsigned nvqs;/* number of virtqueues in vqs[] */
>  unsigned vqs[];   /* virtqueues to process */
>  };
>
>  struct vhost_run_worker_info {
>   struct timespec *timeout;
>   sigset_t *sigmask;
>
>   unsigned ndevices;
>   struct vhost_run_worker_dev *devices[];
>  };
>
> In the simple case userspace sets ndevices to 1 and we just handle
> virtqueues for the current device.
>
> In the fancier shared worker thread case the userspace process has the
> vhost fds of all the devices it is processing and passes them to
> ioctl(VHOST_WORKER_RUN) via struct vhost_run_worker_dev elements.

Which fd will be used for this IOCTL? One of the 'vhostfd' or we should
create a new /dev/vhost-workers (or something similar)?

Maybe the new device will be cleaner and can be reused also for other stuff
(I'm thinking about vDPA software devices).

>
> From a security perspective it means the userspace thread has access to
> all vhost devices (because it has their fds).
>
> I'm not sure how the mm is supposed to work. The devices might be
> associated with different userspace processes (guests) and therefore
>

Re: [PATCH 1/1] qemu vhost scsi: add VHOST_SET_VRING_ENABLE support

On Thu, Nov 12, 2020 at 05:19:00PM -0600, Mike Christie wrote:
> diff --git a/linux-headers/linux/vhost.h b/linux-headers/linux/vhost.h
> index 7523218..98dd919 100644
> --- a/linux-headers/linux/vhost.h
> +++ b/linux-headers/linux/vhost.h
> @@ -70,6 +70,7 @@
>  #define VHOST_VRING_BIG_ENDIAN 1
>  #define VHOST_SET_VRING_ENDIAN _IOW(VHOST_VIRTIO, 0x13, struct 
> vhost_vring_state)
>  #define VHOST_GET_VRING_ENDIAN _IOW(VHOST_VIRTIO, 0x14, struct 
> vhost_vring_state)
> +#define VHOST_SET_VRING_ENABLE _IOW(VHOST_VIRTIO, 0x15, struct 
> vhost_vring_state)

OK so first we need the kernel patches, then update the header, then
we can apply the qemu patch.

>  /* The following ioctls use eventfd file descriptors to signal and poll
>   * for events. */
> -- 
> 1.8.3.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance

On Wed, Dec 02, 2020 at 12:18:36PM +0800, Jason Wang wrote:
> 
> On 2020/12/1 下午5:23, Cindy Lu wrote:
> > On Mon, Nov 30, 2020 at 11:33 PM Michael S. Tsirkin  wrote:
> > > On Mon, Nov 30, 2020 at 06:41:45PM +0800, Cindy Lu wrote:
> > > > On Mon, Nov 30, 2020 at 5:33 PM Michael S. Tsirkin  
> > > > wrote:
> > > > > On Mon, Nov 30, 2020 at 11:27:59AM +0200, Eli Cohen wrote:
> > > > > > On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. Tsirkin wrote:
> > > > > > > On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:
> > > > > > > > On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. Tsirkin 
> > > > > > > > wrote:
> > > > > > > > > On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen wrote:
> > > > > > > > > > We should not try to use the VF MAC address as that is used 
> > > > > > > > > > by the
> > > > > > > > > > regular (e.g. mlx5_core) NIC implementation. Instead, use a 
> > > > > > > > > > random
> > > > > > > > > > generated MAC address.
> > > > > > > > > > 
> > > > > > > > > > Suggested by: Cindy Lu 
> > > > > > > > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for 
> > > > > > > > > > supported mlx5 devices")
> > > > > > > > > > Signed-off-by: Eli Cohen 
> > > > > > > > > I didn't realise it's possible to use VF in two ways
> > > > > > > > > with and without vdpa.
> > > > > > > > Using a VF you can create quite a few resources, e.g. send 
> > > > > > > > queues
> > > > > > > > recieve queues, virtio_net queues etc. So you can possibly 
> > > > > > > > create
> > > > > > > > several instances of vdpa net devices and nic net devices.
> > > > > > > > 
> > > > > > > > > Could you include a bit more description on the failure
> > > > > > > > > mode?
> > > > > > > > Well, using the MAC address of the nic vport is wrong since 
> > > > > > > > that is the
> > > > > > > > MAC of the regular NIC implementation of mlx5_core.
> > > > > > > Right but ATM it doesn't coexist with vdpa so what's the problem?
> > > > > > > 
> > > > > > This call is wrong:  mlx5_query_nic_vport_mac_address()
> > > > > > 
> > > > > > > > > Is switching to a random mac for such an unusual
> > > > > > > > > configuration really justified?
> > > > > > > > Since I can't use the NIC's MAC address, I have two options:
> > > > > > > > 1. To get the MAC address as was chosen by the user 
> > > > > > > > administering the
> > > > > > > > NIC. This should invoke the set_config callback. 
> > > > > > > > Unfortunately this
> > > > > > > > is not implemented yet.
> > > > > > > > 
> > > > > > > > 2. Use a random MAC address. This is OK since if (1) is 
> > > > > > > > implemented it
> > > > > > > > can always override this random configuration.
> > > > > > > > 
> > > > > > > > > It looks like changing a MAC could break some guests,
> > > > > > > > > can it not?
> > > > > > > > > 
> > > > > > > > No, it will not. The current version of mlx5 VDPA does not 
> > > > > > > > allow regular
> > > > > > > > NIC driver and VDPA to co-exist. I have patches ready that 
> > > > > > > > enable that
> > > > > > > > from steering point of view. I will post them here once other 
> > > > > > > > patches on
> > > > > > > > which they depend will be merged.
> > > > > > > > 
> > > > > > > > https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/
> > > > > > > Could you be more explicit on the following points:
> > > > > > > - which configuration is broken ATM (as in, two device have 
> > > > > > > identical
> > > > > > >macs? any other issues)?
> > > > > > The only wrong thing is the call to  
> > > > > > mlx5_query_nic_vport_mac_address().
> > > > > > It's not breaking anything yet is wrong. The random MAC address 
> > > > > > setting
> > > > > > is required for the steering patches.
> > > > > Okay so I'm not sure the Fixes tag at least is appropriate if it's a
> > > > > dependency of a new feature.
> > > > > 
> > > > > > > - why won't device MAC change from guest point of view?
> > > > > > > 
> > > > > > It's lack of implementation in qemu as far as I know.
> > > > > Sorry not sure I understand. What's not implemented in QEMU?
> > > > > 
> > > > HI Michael, there are some bug in qemu to set_config, this will fix in 
> > > > future,
> > > > But this patch is still needed, because without this patch the mlx
> > > > driver will give an 0 mac address to qemu
> > > > and qemu will overwrite the default mac address.  This will cause 
> > > > traffic down.
> > > Hmm the patch description says VF mac address, not 0 address. Confused.
> > > If there's no mac we can clear VIRTIO_NET_F_MAC and have guest
> > > use a random value ...
> 
> 
> I'm not sure this can work for all types of vDPA (e.g it could not be a
> learning bridge in the swtich).
> 
> 
> > > 
> > hi Michael，
> > I have tried as your suggestion, seems even remove the
> > VIRTIO_NET_F_MAC the qemu will still call get_cinfig and overwrite the
> > default address in  VM,
> 
> 
> This looks a bug in qemu, in guest driver we had:
> 
>     /*

Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance

On Wed, Dec 02, 2020 at 07:57:14AM +0200, Eli Cohen wrote:
> On Wed, Dec 02, 2020 at 12:18:36PM +0800, Jason Wang wrote:
> > 
> > On 2020/12/1 下午5:23, Cindy Lu wrote:
> > > On Mon, Nov 30, 2020 at 11:33 PM Michael S. Tsirkin  
> > > wrote:
> > > > On Mon, Nov 30, 2020 at 06:41:45PM +0800, Cindy Lu wrote:
> > > > > On Mon, Nov 30, 2020 at 5:33 PM Michael S. Tsirkin  
> > > > > wrote:
> > > > > > On Mon, Nov 30, 2020 at 11:27:59AM +0200, Eli Cohen wrote:
> > > > > > > On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. Tsirkin 
> > > > > > > wrote:
> > > > > > > > On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:
> > > > > > > > > On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. Tsirkin 
> > > > > > > > > wrote:
> > > > > > > > > > On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen wrote:
> > > > > > > > > > > We should not try to use the VF MAC address as that is 
> > > > > > > > > > > used by the
> > > > > > > > > > > regular (e.g. mlx5_core) NIC implementation. Instead, use 
> > > > > > > > > > > a random
> > > > > > > > > > > generated MAC address.
> > > > > > > > > > > 
> > > > > > > > > > > Suggested by: Cindy Lu 
> > > > > > > > > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for 
> > > > > > > > > > > supported mlx5 devices")
> > > > > > > > > > > Signed-off-by: Eli Cohen 
> > > > > > > > > > I didn't realise it's possible to use VF in two ways
> > > > > > > > > > with and without vdpa.
> > > > > > > > > Using a VF you can create quite a few resources, e.g. send 
> > > > > > > > > queues
> > > > > > > > > recieve queues, virtio_net queues etc. So you can possibly 
> > > > > > > > > create
> > > > > > > > > several instances of vdpa net devices and nic net devices.
> > > > > > > > > 
> > > > > > > > > > Could you include a bit more description on the failure
> > > > > > > > > > mode?
> > > > > > > > > Well, using the MAC address of the nic vport is wrong since 
> > > > > > > > > that is the
> > > > > > > > > MAC of the regular NIC implementation of mlx5_core.
> > > > > > > > Right but ATM it doesn't coexist with vdpa so what's the 
> > > > > > > > problem?
> > > > > > > > 
> > > > > > > This call is wrong:  mlx5_query_nic_vport_mac_address()
> > > > > > > 
> > > > > > > > > > Is switching to a random mac for such an unusual
> > > > > > > > > > configuration really justified?
> > > > > > > > > Since I can't use the NIC's MAC address, I have two options:
> > > > > > > > > 1. To get the MAC address as was chosen by the user 
> > > > > > > > > administering the
> > > > > > > > > NIC. This should invoke the set_config callback. 
> > > > > > > > > Unfortunately this
> > > > > > > > > is not implemented yet.
> > > > > > > > > 
> > > > > > > > > 2. Use a random MAC address. This is OK since if (1) is 
> > > > > > > > > implemented it
> > > > > > > > > can always override this random configuration.
> > > > > > > > > 
> > > > > > > > > > It looks like changing a MAC could break some guests,
> > > > > > > > > > can it not?
> > > > > > > > > > 
> > > > > > > > > No, it will not. The current version of mlx5 VDPA does not 
> > > > > > > > > allow regular
> > > > > > > > > NIC driver and VDPA to co-exist. I have patches ready that 
> > > > > > > > > enable that
> > > > > > > > > from steering point of view. I will post them here once other 
> > > > > > > > > patches on
> > > > > > > > > which they depend will be merged.
> > > > > > > > > 
> > > > > > > > > https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/
> > > > > > > > Could you be more explicit on the following points:
> > > > > > > > - which configuration is broken ATM (as in, two device have 
> > > > > > > > identical
> > > > > > > >macs? any other issues)?
> > > > > > > The only wrong thing is the call to  
> > > > > > > mlx5_query_nic_vport_mac_address().
> > > > > > > It's not breaking anything yet is wrong. The random MAC address 
> > > > > > > setting
> > > > > > > is required for the steering patches.
> > > > > > Okay so I'm not sure the Fixes tag at least is appropriate if it's a
> > > > > > dependency of a new feature.
> > > > > > 
> > > > > > > > - why won't device MAC change from guest point of view?
> > > > > > > > 
> > > > > > > It's lack of implementation in qemu as far as I know.
> > > > > > Sorry not sure I understand. What's not implemented in QEMU?
> > > > > > 
> > > > > HI Michael, there are some bug in qemu to set_config, this will fix 
> > > > > in future,
> > > > > But this patch is still needed, because without this patch the mlx
> > > > > driver will give an 0 mac address to qemu
> > > > > and qemu will overwrite the default mac address.  This will cause 
> > > > > traffic down.
> > > > Hmm the patch description says VF mac address, not 0 address. Confused.
> > > > If there's no mac we can clear VIRTIO_NET_F_MAC and have guest
> > > > use a random value ...
> > 
> > 
> > I'm not sure this can work for all types of vDPA (e.g it could not be a
> > learning

Re: [PATCH] vhost_vdpa: return -EFAULT if copy_to_user() fails

2020-12-02 Thread Stefano Garzarella


On Wed, Dec 02, 2020 at 09:44:43AM +0300, Dan Carpenter wrote:

The copy_to_user() function returns the number of bytes remaining to be
copied but this should return -EFAULT to the user.

Fixes: 1b48dc03e575 ("vhost: vdpa: report iova range")
Signed-off-by: Dan Carpenter 
---
drivers/vhost/vdpa.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)


Reviewed-by: Stefano Garzarella 



diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index d6a37b66770b..ef688c8c0e0e 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -344,7 +344,9 @@ static long vhost_vdpa_get_iova_range(struct vhost_vdpa *v, 
u32 __user *argp)
.last = v->range.last,
};

-   return copy_to_user(argp, , sizeof(range));
+   if (copy_to_user(argp, , sizeof(range)))
+   return -EFAULT;
+   return 0;
}

static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int cmd,
--
2.29.2

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization



___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces


Hi

Am 02.12.20 um 09:43 schrieb Christian König:

Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:

Hi

Am 01.12.20 um 11:40 schrieb Christian König:
Reviewed-by: Christian König  on patch #1 
and #15.


Acked-by: Christian König  on patch #2 and 
#16.


Could you add these patches to the AMD tree?


Alex is usually the one who picks such stuff up.

But when people send out patch sets which mix changes from different 
drivers it is more common to push them through drm-misc-next.


I'm OK with drm-misc-next. I just don't want to add too many merge 
conflicts in your side.


Best regards
Thomas



Regards,
Christian.



Best regards
Thomas



Regards,
Christian.

Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:

Adhere to kernel coding style.

Signed-off-by: Thomas Zimmermann 
Acked-by: Alex Deucher 
Acked-by: Sam Ravnborg 
Cc: Alex Deucher 
Cc: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

index 5f304425c948..da23c0f21311 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4922,8 +4922,8 @@ pci_ers_result_t 
amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta

  case pci_channel_io_normal:
  return PCI_ERS_RESULT_CAN_RECOVER;
  /* Fatal error, prepare for slot reset */
-    case pci_channel_io_frozen:
-    /*
+    case pci_channel_io_frozen:
+    /*
   * Cancel and wait for all TDRs in progress if failing to
   * set  adev->in_gpu_reset in amdgpu_device_lock_adev
   *
@@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct 
pci_dev *pdev)

  goto out;
  }
-    adev->in_pci_err_recovery = true;
+    adev->in_pci_err_recovery = true;
  r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset);
  adev->in_pci_err_recovery = false;
  if (r)








--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces

2020-12-02 Thread Christian König


Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:

Hi

Am 01.12.20 um 11:40 schrieb Christian König:
Reviewed-by: Christian König  on patch #1 
and #15.


Acked-by: Christian König  on patch #2 and 
#16.


Could you add these patches to the AMD tree?


Alex is usually the one who picks such stuff up.

But when people send out patch sets which mix changes from different 
drivers it is more common to push them through drm-misc-next.


Regards,
Christian.



Best regards
Thomas



Regards,
Christian.

Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:

Adhere to kernel coding style.

Signed-off-by: Thomas Zimmermann 
Acked-by: Alex Deucher 
Acked-by: Sam Ravnborg 
Cc: Alex Deucher 
Cc: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

index 5f304425c948..da23c0f21311 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4922,8 +4922,8 @@ pci_ers_result_t 
amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta

  case pci_channel_io_normal:
  return PCI_ERS_RESULT_CAN_RECOVER;
  /* Fatal error, prepare for slot reset */
-    case pci_channel_io_frozen:
-    /*
+    case pci_channel_io_frozen:
+    /*
   * Cancel and wait for all TDRs in progress if failing to
   * set  adev->in_gpu_reset in amdgpu_device_lock_adev
   *
@@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct 
pci_dev *pdev)

  goto out;
  }
-    adev->in_pci_err_recovery = true;
+    adev->in_pci_err_recovery = true;
  r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset);
  adev->in_pci_err_recovery = false;
  if (r)






___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vhost_vdpa: return -EFAULT if copy_to_user() fails



On 2020/12/2 下午2:44, Dan Carpenter wrote:

The copy_to_user() function returns the number of bytes remaining to be
copied but this should return -EFAULT to the user.

Fixes: 1b48dc03e575 ("vhost: vdpa: report iova range")
Signed-off-by: Dan Carpenter 
---
  drivers/vhost/vdpa.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index d6a37b66770b..ef688c8c0e0e 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -344,7 +344,9 @@ static long vhost_vdpa_get_iova_range(struct vhost_vdpa *v, 
u32 __user *argp)
.last = v->range.last,
};
  
-	return copy_to_user(argp, , sizeof(range));

+   if (copy_to_user(argp, , sizeof(range)))
+   return -EFAULT;
+   return 0;
  }
  
  static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int cmd,



Acked-by: Jason Wang 

Thanks


___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 18/20] drm/virtgpu: Remove references to struct drm_device.pdev

On Tue, Dec 01, 2020 at 11:35:40AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert virtgpu to struct
> drm_device.dev. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Sam Ravnborg 
> Cc: Gerd Hoffmann 

Acked-by: Gerd Hoffmann 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 14/20] drm/qxl: Remove references to struct drm_device.pdev

On Tue, Dec 01, 2020 at 11:35:36AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert qxl to struct
> drm_device.dev. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Sam Ravnborg 
> Cc: Gerd Hoffmann 

Acked-by: Gerd Hoffmann 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 05/20] drm/cirrus: Remove references to struct drm_device.pdev

On Tue, Dec 01, 2020 at 11:35:27AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert cirrus to struct
> drm_device.dev. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Sam Ravnborg 
> Cc: Gerd Hoffmann 

Acked-by: Gerd Hoffmann 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 04/20] drm/bochs: Remove references to struct drm_device.pdev

On Tue, Dec 01, 2020 at 11:35:26AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert bochs to struct
> drm_device.dev. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Sam Ravnborg 
> Cc: Gerd Hoffmann 

Acked-by: Gerd Hoffmann 

> ---
>  drivers/gpu/drm/bochs/bochs_drv.c | 1 -
>  drivers/gpu/drm/bochs/bochs_hw.c  | 4 ++--
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
> b/drivers/gpu/drm/bochs/bochs_drv.c
> index fd454225fd19..b469624fe40d 100644
> --- a/drivers/gpu/drm/bochs/bochs_drv.c
> +++ b/drivers/gpu/drm/bochs/bochs_drv.c
> @@ -121,7 +121,6 @@ static int bochs_pci_probe(struct pci_dev *pdev,
>   if (ret)
>   goto err_free_dev;
>  
> - dev->pdev = pdev;
>   pci_set_drvdata(pdev, dev);
>  
>   ret = bochs_load(dev);
> diff --git a/drivers/gpu/drm/bochs/bochs_hw.c 
> b/drivers/gpu/drm/bochs/bochs_hw.c
> index dce4672e3fc8..2d7380a9890e 100644
> --- a/drivers/gpu/drm/bochs/bochs_hw.c
> +++ b/drivers/gpu/drm/bochs/bochs_hw.c
> @@ -110,7 +110,7 @@ int bochs_hw_load_edid(struct bochs_device *bochs)
>  int bochs_hw_init(struct drm_device *dev)
>  {
>   struct bochs_device *bochs = dev->dev_private;
> - struct pci_dev *pdev = dev->pdev;
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
>   unsigned long addr, size, mem, ioaddr, iosize;
>   u16 id;
>  
> @@ -201,7 +201,7 @@ void bochs_hw_fini(struct drm_device *dev)
>   release_region(VBE_DISPI_IOPORT_INDEX, 2);
>   if (bochs->fb_map)
>   iounmap(bochs->fb_map);
> - pci_release_regions(dev->pdev);
> + pci_release_regions(to_pci_dev(dev->dev));
>   kfree(bochs->edid);
>  }
>  
> -- 
> 2.29.2
> 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev


Hi

Am 30.11.20 um 21:59 schrieb Zack Rusin:




On Nov 24, 2020, at 06:38, Thomas Zimmermann  wrote:

Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Roland Scheidegger 
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |  8 
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-


Reviewed-by: Zack Rusin 


Could you add this patch to the vmwgfx tree?

Best regards
Thomas



z



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces