[PATCH v4 0/8] xen/9pfs: introduce the Xen 9pfs backend

[PATCH v4 0/8] xen/9pfs: introduce the Xen 9pfs backend

[Stefano Stabellini]

Hi all,

This patch series implements a new transport for 9pfs, aimed at Xen
systems.

The transport is based on a traditional Xen frontend and backend drivers
pair. This patch series implements the backend, which typically runs in
Dom0. I sent another series to implement the frontend in Linux
(http://marc.info/?l=linux-kernel&m=148883047125960&w=2).

The backend complies to the Xen transport for 9pfs specification
version 1, available here:

https://xenbits.xen.org/docs/unstable/misc/9pfs.html


Changes in v4:
- add reviewed-bys
- remove useless if(NULL) checks around g_free
- g_free g_malloc'ed sgs
- remove XEN_9PFS_RING_ORDER, make the ring order dynamic per ring,
  reading the ring_order field in xen_9pfs_data_intf
- remove patch not to build Xen backends on non-Xen capable targets
  because it is already upstream

Changes in v3:
- do not build backends for targets that do not support xen
- remove xen_9pfs.h, merge its content into xen-9p-backend.c
- remove xen_9pfs_header, introduce P9MsgHeader
- use le32_to_cpu to access P9MsgHeader fields
- many coding style fixes
- run checkpatch on all patches
- add check if num_rings < 1
- use g_strdup_printf
- free fsdev_id in xen_9pfs_free
- add comments

Changes in v2:
- fix coding style
- compile xen-9p-backend.c if CONFIG_XEN_BACKEND
- add patch to set CONFIG_XEN_BACKEND only for the right targets
- add review-bys


Stefano Stabellini (8):
      xen: import ring.h from xen
      9p: introduce a type for the 9p header
      xen/9pfs: introduce Xen 9pfs backend
      xen/9pfs: connect to the frontend
      xen/9pfs: receive requests from the frontend
      xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal
      xen/9pfs: send responses back to the frontend
      xen/9pfs: build and register Xen 9pfs backend

 hw/9pfs/9p.h                 |   6 +
 hw/9pfs/Makefile.objs        |   1 +
 hw/9pfs/virtio-9p-device.c   |   6 +-
 hw/9pfs/xen-9p-backend.c     | 444 +++++++++++++++++++++++++++++++++++++++++
 hw/block/xen_blkif.h         |   2 +-
 hw/usb/xen-usb.c             |   2 +-
 hw/xen/xen_backend.c         |   3 +
 include/hw/xen/io/ring.h     | 455 +++++++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |   3 +
 9 files changed, 915 insertions(+), 7 deletions(-)
 create mode 100644 hw/9pfs/xen-9p-backend.c
 create mode 100644 include/hw/xen/io/ring.h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v4 0/8] xen/9pfs: introduce the Xen 9pfs backend

[Greg Kurz]

[-- Attachment #1.1: Type: text/plain, Size: 2907 bytes --]

On Mon, 20 Mar 2017 11:18:46 -0700 (PDT)
Stefano Stabellini <sstabellini@kernel.org> wrote:

> Hi all,
> 
> This patch series implements a new transport for 9pfs, aimed at Xen
> systems.
> 
> The transport is based on a traditional Xen frontend and backend drivers
> pair. This patch series implements the backend, which typically runs in
> Dom0. I sent another series to implement the frontend in Linux
> (http://marc.info/?l=linux-kernel&m=148883047125960&w=2).
> 
> The backend complies to the Xen transport for 9pfs specification
> version 1, available here:
> 
> https://xenbits.xen.org/docs/unstable/misc/9pfs.html
> 
> 
> Changes in v4:
> - add reviewed-bys
> - remove useless if(NULL) checks around g_free
> - g_free g_malloc'ed sgs
> - remove XEN_9PFS_RING_ORDER, make the ring order dynamic per ring,
>   reading the ring_order field in xen_9pfs_data_intf
> - remove patch not to build Xen backends on non-Xen capable targets
>   because it is already upstream
> 

Hi Stefano,

This looks good to me. Do you want these patches to go through my 9p
tree or through your xen tree ? Also, I guess you may want to add
F: hw/9pfs/xen-9p-backend.c to the Xen section in MAINTAINERS.

Cheers,

--
Greg

> Changes in v3:
> - do not build backends for targets that do not support xen
> - remove xen_9pfs.h, merge its content into xen-9p-backend.c
> - remove xen_9pfs_header, introduce P9MsgHeader
> - use le32_to_cpu to access P9MsgHeader fields
> - many coding style fixes
> - run checkpatch on all patches
> - add check if num_rings < 1
> - use g_strdup_printf
> - free fsdev_id in xen_9pfs_free
> - add comments
> 
> Changes in v2:
> - fix coding style
> - compile xen-9p-backend.c if CONFIG_XEN_BACKEND
> - add patch to set CONFIG_XEN_BACKEND only for the right targets
> - add review-bys
> 
> 
> Stefano Stabellini (8):
>       xen: import ring.h from xen
>       9p: introduce a type for the 9p header
>       xen/9pfs: introduce Xen 9pfs backend
>       xen/9pfs: connect to the frontend
>       xen/9pfs: receive requests from the frontend
>       xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal
>       xen/9pfs: send responses back to the frontend
>       xen/9pfs: build and register Xen 9pfs backend
> 
>  hw/9pfs/9p.h                 |   6 +
>  hw/9pfs/Makefile.objs        |   1 +
>  hw/9pfs/virtio-9p-device.c   |   6 +-
>  hw/9pfs/xen-9p-backend.c     | 444 +++++++++++++++++++++++++++++++++++++++++
>  hw/block/xen_blkif.h         |   2 +-
>  hw/usb/xen-usb.c             |   2 +-
>  hw/xen/xen_backend.c         |   3 +
>  include/hw/xen/io/ring.h     | 455 +++++++++++++++++++++++++++++++++++++++++++
>  include/hw/xen/xen_backend.h |   3 +
>  9 files changed, 915 insertions(+), 7 deletions(-)
>  create mode 100644 hw/9pfs/xen-9p-backend.c
>  create mode 100644 include/hw/xen/io/ring.h


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Qemu-devel] [PATCH v4 0/8] xen/9pfs: introduce the Xen 9pfs backend

[Stefano Stabellini]

On Tue, 21 Mar 2017, Greg Kurz wrote:
> On Mon, 20 Mar 2017 11:18:46 -0700 (PDT)
> Stefano Stabellini <sstabellini@kernel.org> wrote:
> 
> > Hi all,
> > 
> > This patch series implements a new transport for 9pfs, aimed at Xen
> > systems.
> > 
> > The transport is based on a traditional Xen frontend and backend drivers
> > pair. This patch series implements the backend, which typically runs in
> > Dom0. I sent another series to implement the frontend in Linux
> > (http://marc.info/?l=linux-kernel&m=148883047125960&w=2).
> > 
> > The backend complies to the Xen transport for 9pfs specification
> > version 1, available here:
> > 
> > https://xenbits.xen.org/docs/unstable/misc/9pfs.html
> > 
> > 
> > Changes in v4:
> > - add reviewed-bys
> > - remove useless if(NULL) checks around g_free
> > - g_free g_malloc'ed sgs
> > - remove XEN_9PFS_RING_ORDER, make the ring order dynamic per ring,
> >   reading the ring_order field in xen_9pfs_data_intf
> > - remove patch not to build Xen backends on non-Xen capable targets
> >   because it is already upstream
> > 
> 
> Hi Stefano,
> 
> This looks good to me. Do you want these patches to go through my 9p
> tree or through your xen tree ?

Thanks Greg! It can work both ways. If you have any changes in your queue
that could conflict with this, it's best to go via your tree.

Otherwise, I'll merge it in mine, so that I can keep an eye on the
correspondent Xen changes to the header files and make sure they are in
sync (specifically http://marc.info/?l=qemu-devel&m=149003412910278).


>  Also, I guess you may want to add
> F: hw/9pfs/xen-9p-backend.c to the Xen section in MAINTAINERS.

I'll send a patch to be applied on top of the series


> --
> Greg
> 
> > Changes in v3:
> > - do not build backends for targets that do not support xen
> > - remove xen_9pfs.h, merge its content into xen-9p-backend.c
> > - remove xen_9pfs_header, introduce P9MsgHeader
> > - use le32_to_cpu to access P9MsgHeader fields
> > - many coding style fixes
> > - run checkpatch on all patches
> > - add check if num_rings < 1
> > - use g_strdup_printf
> > - free fsdev_id in xen_9pfs_free
> > - add comments
> > 
> > Changes in v2:
> > - fix coding style
> > - compile xen-9p-backend.c if CONFIG_XEN_BACKEND
> > - add patch to set CONFIG_XEN_BACKEND only for the right targets
> > - add review-bys
> > 
> > 
> > Stefano Stabellini (8):
> >       xen: import ring.h from xen
> >       9p: introduce a type for the 9p header
> >       xen/9pfs: introduce Xen 9pfs backend
> >       xen/9pfs: connect to the frontend
> >       xen/9pfs: receive requests from the frontend
> >       xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal
> >       xen/9pfs: send responses back to the frontend
> >       xen/9pfs: build and register Xen 9pfs backend
> > 
> >  hw/9pfs/9p.h                 |   6 +
> >  hw/9pfs/Makefile.objs        |   1 +
> >  hw/9pfs/virtio-9p-device.c   |   6 +-
> >  hw/9pfs/xen-9p-backend.c     | 444 +++++++++++++++++++++++++++++++++++++++++
> >  hw/block/xen_blkif.h         |   2 +-
> >  hw/usb/xen-usb.c             |   2 +-
> >  hw/xen/xen_backend.c         |   3 +
> >  include/hw/xen/io/ring.h     | 455 +++++++++++++++++++++++++++++++++++++++++++
> >  include/hw/xen/xen_backend.h |   3 +
> >  9 files changed, 915 insertions(+), 7 deletions(-)
> >  create mode 100644 hw/9pfs/xen-9p-backend.c
> >  create mode 100644 include/hw/xen/io/ring.h
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Qemu-devel] [PATCH v4 0/8] xen/9pfs: introduce the Xen 9pfs backend

[Greg Kurz]

[-- Attachment #1.1: Type: text/plain, Size: 3964 bytes --]

On Tue, 21 Mar 2017 13:14:02 -0700 (PDT)
Stefano Stabellini <sstabellini@kernel.org> wrote:

> On Tue, 21 Mar 2017, Greg Kurz wrote:
> > On Mon, 20 Mar 2017 11:18:46 -0700 (PDT)
> > Stefano Stabellini <sstabellini@kernel.org> wrote:
> >   
> > > Hi all,
> > > 
> > > This patch series implements a new transport for 9pfs, aimed at Xen
> > > systems.
> > > 
> > > The transport is based on a traditional Xen frontend and backend drivers
> > > pair. This patch series implements the backend, which typically runs in
> > > Dom0. I sent another series to implement the frontend in Linux
> > > (http://marc.info/?l=linux-kernel&m=148883047125960&w=2).
> > > 
> > > The backend complies to the Xen transport for 9pfs specification
> > > version 1, available here:
> > > 
> > > https://xenbits.xen.org/docs/unstable/misc/9pfs.html
> > > 
> > > 
> > > Changes in v4:
> > > - add reviewed-bys
> > > - remove useless if(NULL) checks around g_free
> > > - g_free g_malloc'ed sgs
> > > - remove XEN_9PFS_RING_ORDER, make the ring order dynamic per ring,
> > >   reading the ring_order field in xen_9pfs_data_intf
> > > - remove patch not to build Xen backends on non-Xen capable targets
> > >   because it is already upstream
> > >   
> > 
> > Hi Stefano,
> > 
> > This looks good to me. Do you want these patches to go through my 9p
> > tree or through your xen tree ?  
> 
> Thanks Greg! It can work both ways. If you have any changes in your queue
> that could conflict with this, it's best to go via your tree.
> 
> Otherwise, I'll merge it in mine, so that I can keep an eye on the
> correspondent Xen changes to the header files and make sure they are in
> sync (specifically http://marc.info/?l=qemu-devel&m=149003412910278).
> 

I don't have any conflicting patches on my side. Please merge this in your
tree (as well as the MAINTAINERS patch).

Cheers,

--
Greg

> 
> >  Also, I guess you may want to add
> > F: hw/9pfs/xen-9p-backend.c to the Xen section in MAINTAINERS.  
> 
> I'll send a patch to be applied on top of the series
> 
> 
> > --
> > Greg
> >   
> > > Changes in v3:
> > > - do not build backends for targets that do not support xen
> > > - remove xen_9pfs.h, merge its content into xen-9p-backend.c
> > > - remove xen_9pfs_header, introduce P9MsgHeader
> > > - use le32_to_cpu to access P9MsgHeader fields
> > > - many coding style fixes
> > > - run checkpatch on all patches
> > > - add check if num_rings < 1
> > > - use g_strdup_printf
> > > - free fsdev_id in xen_9pfs_free
> > > - add comments
> > > 
> > > Changes in v2:
> > > - fix coding style
> > > - compile xen-9p-backend.c if CONFIG_XEN_BACKEND
> > > - add patch to set CONFIG_XEN_BACKEND only for the right targets
> > > - add review-bys
> > > 
> > > 
> > > Stefano Stabellini (8):
> > >       xen: import ring.h from xen
> > >       9p: introduce a type for the 9p header
> > >       xen/9pfs: introduce Xen 9pfs backend
> > >       xen/9pfs: connect to the frontend
> > >       xen/9pfs: receive requests from the frontend
> > >       xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal
> > >       xen/9pfs: send responses back to the frontend
> > >       xen/9pfs: build and register Xen 9pfs backend
> > > 
> > >  hw/9pfs/9p.h                 |   6 +
> > >  hw/9pfs/Makefile.objs        |   1 +
> > >  hw/9pfs/virtio-9p-device.c   |   6 +-
> > >  hw/9pfs/xen-9p-backend.c     | 444 +++++++++++++++++++++++++++++++++++++++++
> > >  hw/block/xen_blkif.h         |   2 +-
> > >  hw/usb/xen-usb.c             |   2 +-
> > >  hw/xen/xen_backend.c         |   3 +
> > >  include/hw/xen/io/ring.h     | 455 +++++++++++++++++++++++++++++++++++++++++++
> > >  include/hw/xen/xen_backend.h |   3 +
> > >  9 files changed, 915 insertions(+), 7 deletions(-)
> > >  create mode 100644 hw/9pfs/xen-9p-backend.c
> > >  create mode 100644 include/hw/xen/io/ring.h  
> > 
> >   


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Qemu-devel] [PATCH v4 0/8] xen/9pfs: introduce the Xen 9pfs backend

[Stefano Stabellini]

On Wed, 22 Mar 2017, Greg Kurz wrote:
> On Tue, 21 Mar 2017 13:14:02 -0700 (PDT)
> Stefano Stabellini <sstabellini@kernel.org> wrote:
> 
> > On Tue, 21 Mar 2017, Greg Kurz wrote:
> > > On Mon, 20 Mar 2017 11:18:46 -0700 (PDT)
> > > Stefano Stabellini <sstabellini@kernel.org> wrote:
> > >   
> > > > Hi all,
> > > > 
> > > > This patch series implements a new transport for 9pfs, aimed at Xen
> > > > systems.
> > > > 
> > > > The transport is based on a traditional Xen frontend and backend drivers
> > > > pair. This patch series implements the backend, which typically runs in
> > > > Dom0. I sent another series to implement the frontend in Linux
> > > > (http://marc.info/?l=linux-kernel&m=148883047125960&w=2).
> > > > 
> > > > The backend complies to the Xen transport for 9pfs specification
> > > > version 1, available here:
> > > > 
> > > > https://xenbits.xen.org/docs/unstable/misc/9pfs.html
> > > > 
> > > > 
> > > > Changes in v4:
> > > > - add reviewed-bys
> > > > - remove useless if(NULL) checks around g_free
> > > > - g_free g_malloc'ed sgs
> > > > - remove XEN_9PFS_RING_ORDER, make the ring order dynamic per ring,
> > > >   reading the ring_order field in xen_9pfs_data_intf
> > > > - remove patch not to build Xen backends on non-Xen capable targets
> > > >   because it is already upstream
> > > >   
> > > 
> > > Hi Stefano,
> > > 
> > > This looks good to me. Do you want these patches to go through my 9p
> > > tree or through your xen tree ?  
> > 
> > Thanks Greg! It can work both ways. If you have any changes in your queue
> > that could conflict with this, it's best to go via your tree.
> > 
> > Otherwise, I'll merge it in mine, so that I can keep an eye on the
> > correspondent Xen changes to the header files and make sure they are in
> > sync (specifically http://marc.info/?l=qemu-devel&m=149003412910278).
> > 
> 
> I don't have any conflicting patches on my side. Please merge this in your
> tree (as well as the MAINTAINERS patch).

All right, thanks! I'll add a reviewed-by you on all patches if for you
is OK.


> > 
> > >  Also, I guess you may want to add
> > > F: hw/9pfs/xen-9p-backend.c to the Xen section in MAINTAINERS.  
> > 
> > I'll send a patch to be applied on top of the series
> > 
> > 
> > > --
> > > Greg
> > >   
> > > > Changes in v3:
> > > > - do not build backends for targets that do not support xen
> > > > - remove xen_9pfs.h, merge its content into xen-9p-backend.c
> > > > - remove xen_9pfs_header, introduce P9MsgHeader
> > > > - use le32_to_cpu to access P9MsgHeader fields
> > > > - many coding style fixes
> > > > - run checkpatch on all patches
> > > > - add check if num_rings < 1
> > > > - use g_strdup_printf
> > > > - free fsdev_id in xen_9pfs_free
> > > > - add comments
> > > > 
> > > > Changes in v2:
> > > > - fix coding style
> > > > - compile xen-9p-backend.c if CONFIG_XEN_BACKEND
> > > > - add patch to set CONFIG_XEN_BACKEND only for the right targets
> > > > - add review-bys
> > > > 
> > > > 
> > > > Stefano Stabellini (8):
> > > >       xen: import ring.h from xen
> > > >       9p: introduce a type for the 9p header
> > > >       xen/9pfs: introduce Xen 9pfs backend
> > > >       xen/9pfs: connect to the frontend
> > > >       xen/9pfs: receive requests from the frontend
> > > >       xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal
> > > >       xen/9pfs: send responses back to the frontend
> > > >       xen/9pfs: build and register Xen 9pfs backend
> > > > 
> > > >  hw/9pfs/9p.h                 |   6 +
> > > >  hw/9pfs/Makefile.objs        |   1 +
> > > >  hw/9pfs/virtio-9p-device.c   |   6 +-
> > > >  hw/9pfs/xen-9p-backend.c     | 444 +++++++++++++++++++++++++++++++++++++++++
> > > >  hw/block/xen_blkif.h         |   2 +-
> > > >  hw/usb/xen-usb.c             |   2 +-
> > > >  hw/xen/xen_backend.c         |   3 +
> > > >  include/hw/xen/io/ring.h     | 455 +++++++++++++++++++++++++++++++++++++++++++
> > > >  include/hw/xen/xen_backend.h |   3 +
> > > >  9 files changed, 915 insertions(+), 7 deletions(-)
> > > >  create mode 100644 hw/9pfs/xen-9p-backend.c
> > > >  create mode 100644 include/hw/xen/io/ring.h  
> > > 
> > >   
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Qemu-devel] [PATCH v4 0/8] xen/9pfs: introduce the Xen 9pfs backend

[Greg Kurz]

[-- Attachment #1.1: Type: text/plain, Size: 4693 bytes --]

On Wed, 22 Mar 2017 11:32:22 -0700 (PDT)
Stefano Stabellini <sstabellini@kernel.org> wrote:

> On Wed, 22 Mar 2017, Greg Kurz wrote:
> > On Tue, 21 Mar 2017 13:14:02 -0700 (PDT)
> > Stefano Stabellini <sstabellini@kernel.org> wrote:
> >   
> > > On Tue, 21 Mar 2017, Greg Kurz wrote:  
> > > > On Mon, 20 Mar 2017 11:18:46 -0700 (PDT)
> > > > Stefano Stabellini <sstabellini@kernel.org> wrote:
> > > >     
> > > > > Hi all,
> > > > > 
> > > > > This patch series implements a new transport for 9pfs, aimed at Xen
> > > > > systems.
> > > > > 
> > > > > The transport is based on a traditional Xen frontend and backend drivers
> > > > > pair. This patch series implements the backend, which typically runs in
> > > > > Dom0. I sent another series to implement the frontend in Linux
> > > > > (http://marc.info/?l=linux-kernel&m=148883047125960&w=2).
> > > > > 
> > > > > The backend complies to the Xen transport for 9pfs specification
> > > > > version 1, available here:
> > > > > 
> > > > > https://xenbits.xen.org/docs/unstable/misc/9pfs.html
> > > > > 
> > > > > 
> > > > > Changes in v4:
> > > > > - add reviewed-bys
> > > > > - remove useless if(NULL) checks around g_free
> > > > > - g_free g_malloc'ed sgs
> > > > > - remove XEN_9PFS_RING_ORDER, make the ring order dynamic per ring,
> > > > >   reading the ring_order field in xen_9pfs_data_intf
> > > > > - remove patch not to build Xen backends on non-Xen capable targets
> > > > >   because it is already upstream
> > > > >     
> > > > 
> > > > Hi Stefano,
> > > > 
> > > > This looks good to me. Do you want these patches to go through my 9p
> > > > tree or through your xen tree ?    
> > > 
> > > Thanks Greg! It can work both ways. If you have any changes in your queue
> > > that could conflict with this, it's best to go via your tree.
> > > 
> > > Otherwise, I'll merge it in mine, so that I can keep an eye on the
> > > correspondent Xen changes to the header files and make sure they are in
> > > sync (specifically http://marc.info/?l=qemu-devel&m=149003412910278).
> > >   
> > 
> > I don't have any conflicting patches on my side. Please merge this in your
> > tree (as well as the MAINTAINERS patch).  
> 
> All right, thanks! I'll add a reviewed-by you on all patches if for you
> is OK.
> 

I'd prefer not as I haven't reviewed the Xen specific bits actually :)

> 
> > >   
> > > >  Also, I guess you may want to add
> > > > F: hw/9pfs/xen-9p-backend.c to the Xen section in MAINTAINERS.    
> > > 
> > > I'll send a patch to be applied on top of the series
> > > 
> > >   
> > > > --
> > > > Greg
> > > >     
> > > > > Changes in v3:
> > > > > - do not build backends for targets that do not support xen
> > > > > - remove xen_9pfs.h, merge its content into xen-9p-backend.c
> > > > > - remove xen_9pfs_header, introduce P9MsgHeader
> > > > > - use le32_to_cpu to access P9MsgHeader fields
> > > > > - many coding style fixes
> > > > > - run checkpatch on all patches
> > > > > - add check if num_rings < 1
> > > > > - use g_strdup_printf
> > > > > - free fsdev_id in xen_9pfs_free
> > > > > - add comments
> > > > > 
> > > > > Changes in v2:
> > > > > - fix coding style
> > > > > - compile xen-9p-backend.c if CONFIG_XEN_BACKEND
> > > > > - add patch to set CONFIG_XEN_BACKEND only for the right targets
> > > > > - add review-bys
> > > > > 
> > > > > 
> > > > > Stefano Stabellini (8):
> > > > >       xen: import ring.h from xen
> > > > >       9p: introduce a type for the 9p header
> > > > >       xen/9pfs: introduce Xen 9pfs backend
> > > > >       xen/9pfs: connect to the frontend
> > > > >       xen/9pfs: receive requests from the frontend
> > > > >       xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal
> > > > >       xen/9pfs: send responses back to the frontend
> > > > >       xen/9pfs: build and register Xen 9pfs backend
> > > > > 
> > > > >  hw/9pfs/9p.h                 |   6 +
> > > > >  hw/9pfs/Makefile.objs        |   1 +
> > > > >  hw/9pfs/virtio-9p-device.c   |   6 +-
> > > > >  hw/9pfs/xen-9p-backend.c     | 444 +++++++++++++++++++++++++++++++++++++++++
> > > > >  hw/block/xen_blkif.h         |   2 +-
> > > > >  hw/usb/xen-usb.c             |   2 +-
> > > > >  hw/xen/xen_backend.c         |   3 +
> > > > >  include/hw/xen/io/ring.h     | 455 +++++++++++++++++++++++++++++++++++++++++++
> > > > >  include/hw/xen/xen_backend.h |   3 +
> > > > >  9 files changed, 915 insertions(+), 7 deletions(-)
> > > > >  create mode 100644 hw/9pfs/xen-9p-backend.c
> > > > >  create mode 100644 include/hw/xen/io/ring.h    
> > > > 
> > > >     
> > 
> >   


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Qemu-devel] [PATCH v4 0/8] xen/9pfs: introduce the Xen 9pfs backend

[Stefano Stabellini]

On Thu, 23 Mar 2017, Greg Kurz wrote:
> On Wed, 22 Mar 2017 11:32:22 -0700 (PDT)
> Stefano Stabellini <sstabellini@kernel.org> wrote:
> 
> > On Wed, 22 Mar 2017, Greg Kurz wrote:
> > > On Tue, 21 Mar 2017 13:14:02 -0700 (PDT)
> > > Stefano Stabellini <sstabellini@kernel.org> wrote:
> > >   
> > > > On Tue, 21 Mar 2017, Greg Kurz wrote:  
> > > > > On Mon, 20 Mar 2017 11:18:46 -0700 (PDT)
> > > > > Stefano Stabellini <sstabellini@kernel.org> wrote:
> > > > >     
> > > > > > Hi all,
> > > > > > 
> > > > > > This patch series implements a new transport for 9pfs, aimed at Xen
> > > > > > systems.
> > > > > > 
> > > > > > The transport is based on a traditional Xen frontend and backend drivers
> > > > > > pair. This patch series implements the backend, which typically runs in
> > > > > > Dom0. I sent another series to implement the frontend in Linux
> > > > > > (http://marc.info/?l=linux-kernel&m=148883047125960&w=2).
> > > > > > 
> > > > > > The backend complies to the Xen transport for 9pfs specification
> > > > > > version 1, available here:
> > > > > > 
> > > > > > https://xenbits.xen.org/docs/unstable/misc/9pfs.html
> > > > > > 
> > > > > > 
> > > > > > Changes in v4:
> > > > > > - add reviewed-bys
> > > > > > - remove useless if(NULL) checks around g_free
> > > > > > - g_free g_malloc'ed sgs
> > > > > > - remove XEN_9PFS_RING_ORDER, make the ring order dynamic per ring,
> > > > > >   reading the ring_order field in xen_9pfs_data_intf
> > > > > > - remove patch not to build Xen backends on non-Xen capable targets
> > > > > >   because it is already upstream
> > > > > >     
> > > > > 
> > > > > Hi Stefano,
> > > > > 
> > > > > This looks good to me. Do you want these patches to go through my 9p
> > > > > tree or through your xen tree ?    
> > > > 
> > > > Thanks Greg! It can work both ways. If you have any changes in your queue
> > > > that could conflict with this, it's best to go via your tree.
> > > > 
> > > > Otherwise, I'll merge it in mine, so that I can keep an eye on the
> > > > correspondent Xen changes to the header files and make sure they are in
> > > > sync (specifically http://marc.info/?l=qemu-devel&m=149003412910278).
> > > >   
> > > 
> > > I don't have any conflicting patches on my side. Please merge this in your
> > > tree (as well as the MAINTAINERS patch).  
> > 
> > All right, thanks! I'll add a reviewed-by you on all patches if for you
> > is OK.
> > 
> 
> I'd prefer not as I haven't reviewed the Xen specific bits actually :)

OK :)


> > > >   
> > > > >  Also, I guess you may want to add
> > > > > F: hw/9pfs/xen-9p-backend.c to the Xen section in MAINTAINERS.    
> > > > 
> > > > I'll send a patch to be applied on top of the series
> > > > 
> > > >   
> > > > > --
> > > > > Greg
> > > > >     
> > > > > > Changes in v3:
> > > > > > - do not build backends for targets that do not support xen
> > > > > > - remove xen_9pfs.h, merge its content into xen-9p-backend.c
> > > > > > - remove xen_9pfs_header, introduce P9MsgHeader
> > > > > > - use le32_to_cpu to access P9MsgHeader fields
> > > > > > - many coding style fixes
> > > > > > - run checkpatch on all patches
> > > > > > - add check if num_rings < 1
> > > > > > - use g_strdup_printf
> > > > > > - free fsdev_id in xen_9pfs_free
> > > > > > - add comments
> > > > > > 
> > > > > > Changes in v2:
> > > > > > - fix coding style
> > > > > > - compile xen-9p-backend.c if CONFIG_XEN_BACKEND
> > > > > > - add patch to set CONFIG_XEN_BACKEND only for the right targets
> > > > > > - add review-bys
> > > > > > 
> > > > > > 
> > > > > > Stefano Stabellini (8):
> > > > > >       xen: import ring.h from xen
> > > > > >       9p: introduce a type for the 9p header
> > > > > >       xen/9pfs: introduce Xen 9pfs backend
> > > > > >       xen/9pfs: connect to the frontend
> > > > > >       xen/9pfs: receive requests from the frontend
> > > > > >       xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal
> > > > > >       xen/9pfs: send responses back to the frontend
> > > > > >       xen/9pfs: build and register Xen 9pfs backend
> > > > > > 
> > > > > >  hw/9pfs/9p.h                 |   6 +
> > > > > >  hw/9pfs/Makefile.objs        |   1 +
> > > > > >  hw/9pfs/virtio-9p-device.c   |   6 +-
> > > > > >  hw/9pfs/xen-9p-backend.c     | 444 +++++++++++++++++++++++++++++++++++++++++
> > > > > >  hw/block/xen_blkif.h         |   2 +-
> > > > > >  hw/usb/xen-usb.c             |   2 +-
> > > > > >  hw/xen/xen_backend.c         |   3 +
> > > > > >  include/hw/xen/io/ring.h     | 455 +++++++++++++++++++++++++++++++++++++++++++
> > > > > >  include/hw/xen/xen_backend.h |   3 +
> > > > > >  9 files changed, 915 insertions(+), 7 deletions(-)
> > > > > >  create mode 100644 hw/9pfs/xen-9p-backend.c
> > > > > >  create mode 100644 include/hw/xen/io/ring.h    
> > > > > 
> > > > >     
> > > 
> > >   
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v4 1/8] xen: import ring.h from xen

[Juergen Gross]

On 23/03/17 19:22, Stefano Stabellini wrote:
> On Thu, 23 Mar 2017, Paolo Bonzini wrote:
>> On 23/03/2017 14:55, Juergen Gross wrote:
>>> On 23/03/17 14:00, Greg Kurz wrote:
>>>> On Mon, 20 Mar 2017 11:19:05 -0700
>>>> Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>>
>>>>> Do not use the ring.h header installed on the system. Instead, import
>>>>> the header into the QEMU codebase. This avoids problems when QEMU is
>>>>> built against a Xen version too old to provide all the ring macros.
>>>>>
>>>>> Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
>>>>> Reviewed-by: Greg Kurz <groug@kaod.org>
>>>>> CC: anthony.perard@citrix.com
>>>>> CC: jgross@suse.com
>>>>> ---
>>>>> NB: The new macros have not been committed to Xen yet. Do not apply this
>>>>> patch until they do.
>>>>> ---
>>>>
>>>> Looking at your other series for the kernel part of this feature:
>>>>
>>>> https://lkml.org/lkml/2017/3/22/761
>>>>
>>>> I realize that the ring.h header from Xen also exists in the kernel tree... 
>>>>
>>>> Shouldn't all the code that can be used in both kernel and userspace go to a
>>>> header file under include/uapi in the kernel tree ? And then we would import
>>>> it under include/standard-headers/linux in the QEMU tree and we could keep it
>>>> in sync using scripts/update-linux-headers.sh.
>>>>
>>>> Cc'ing Paolo for insights.
>>>
>>> As Xen isn't part of the kernel we don't want that. You can use and/or
>>> build qemu with xen-9pfs backend support on an old Linux kernel without
>>> the related frontend.
>>
>> As long as the header changes rarely, I guess it's fine not to go
>> through update-linux-headers.sh.
> 
> Very rarely, last time ring.h was changed was 2015, and to introduce a
> new macro (which we don't necessarily need in QEMU).
> 
> 
>>> OTOH I don't see the advantage of not using the headers from Xen. This
>>> is working for qdisk and pvusb backends and for all the Xen libraries.
>>> Do you expect the 9pfs backend to be used for a qemu version built
>>> against a Xen version not supporting that backend?
> 
> Yes, I think that is entirely possible: Xen and QEMU versions can mix
> and match.
> 
> Keeping in mind that the 9pfs backend has actually no build dependencies
> on Xen, except for these new ring.h macros, we have the following
> options:
> 
> 1) we build the 9pfs backend only for Xen >= 4.9, because of the new
>    macros in ring.h that we need

Right. You have sent 9pfs support patches for Xen tools. So obviously
you need a proper Xen version to use 9pfs. Why not build qemu against
it? Do you really expect a new Xen being used with an old qemu while
wanting to use new features? That makes no sense for me.


Juergen

PS: added xen-devel as this should be discussed there, too.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v4 1/8] xen: import ring.h from xen

[Stefano Stabellini]

On Fri, 24 Mar 2017, Juergen Gross wrote:
> On 23/03/17 19:22, Stefano Stabellini wrote:
> > On Thu, 23 Mar 2017, Paolo Bonzini wrote:
> >> On 23/03/2017 14:55, Juergen Gross wrote:
> >>> On 23/03/17 14:00, Greg Kurz wrote:
> >>>> On Mon, 20 Mar 2017 11:19:05 -0700
> >>>> Stefano Stabellini <sstabellini@kernel.org> wrote:
> >>>>
> >>>>> Do not use the ring.h header installed on the system. Instead, import
> >>>>> the header into the QEMU codebase. This avoids problems when QEMU is
> >>>>> built against a Xen version too old to provide all the ring macros.
> >>>>>
> >>>>> Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
> >>>>> Reviewed-by: Greg Kurz <groug@kaod.org>
> >>>>> CC: anthony.perard@citrix.com
> >>>>> CC: jgross@suse.com
> >>>>> ---
> >>>>> NB: The new macros have not been committed to Xen yet. Do not apply this
> >>>>> patch until they do.
> >>>>> ---
> >>>>
> >>>> Looking at your other series for the kernel part of this feature:
> >>>>
> >>>> https://lkml.org/lkml/2017/3/22/761
> >>>>
> >>>> I realize that the ring.h header from Xen also exists in the kernel tree... 
> >>>>
> >>>> Shouldn't all the code that can be used in both kernel and userspace go to a
> >>>> header file under include/uapi in the kernel tree ? And then we would import
> >>>> it under include/standard-headers/linux in the QEMU tree and we could keep it
> >>>> in sync using scripts/update-linux-headers.sh.
> >>>>
> >>>> Cc'ing Paolo for insights.
> >>>
> >>> As Xen isn't part of the kernel we don't want that. You can use and/or
> >>> build qemu with xen-9pfs backend support on an old Linux kernel without
> >>> the related frontend.
> >>
> >> As long as the header changes rarely, I guess it's fine not to go
> >> through update-linux-headers.sh.
> > 
> > Very rarely, last time ring.h was changed was 2015, and to introduce a
> > new macro (which we don't necessarily need in QEMU).
> > 
> > 
> >>> OTOH I don't see the advantage of not using the headers from Xen. This
> >>> is working for qdisk and pvusb backends and for all the Xen libraries.
> >>> Do you expect the 9pfs backend to be used for a qemu version built
> >>> against a Xen version not supporting that backend?
> > 
> > Yes, I think that is entirely possible: Xen and QEMU versions can mix
> > and match.
> > 
> > Keeping in mind that the 9pfs backend has actually no build dependencies
> > on Xen, except for these new ring.h macros, we have the following
> > options:
> > 
> > 1) we build the 9pfs backend only for Xen >= 4.9, because of the new
> >    macros in ring.h that we need
> 
> Right. You have sent 9pfs support patches for Xen tools. So obviously
> you need a proper Xen version to use 9pfs. Why not build qemu against
> it? Do you really expect a new Xen being used with an old qemu while
> wanting to use new features? That makes no sense for me.
 
Tools support is needed to setup the frontend/backend connection as
usual, but that's not a requirement for building the 9pfs backend. In
fact, the backend doesn't need any tools support for it to work. The
macro themselves are just a convenience - the backend would work just
fine without them. Why restrict the QEMU build gratuitously?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v4 1/8] xen: import ring.h from xen

[Juergen Gross]

On 24/03/17 18:37, Stefano Stabellini wrote:
> On Fri, 24 Mar 2017, Juergen Gross wrote:
>> On 23/03/17 19:22, Stefano Stabellini wrote:
>>> On Thu, 23 Mar 2017, Paolo Bonzini wrote:
>>>> On 23/03/2017 14:55, Juergen Gross wrote:
>>>>> On 23/03/17 14:00, Greg Kurz wrote:
>>>>>> On Mon, 20 Mar 2017 11:19:05 -0700
>>>>>> Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>>>>
>>>>>>> Do not use the ring.h header installed on the system. Instead, import
>>>>>>> the header into the QEMU codebase. This avoids problems when QEMU is
>>>>>>> built against a Xen version too old to provide all the ring macros.
>>>>>>>
>>>>>>> Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
>>>>>>> Reviewed-by: Greg Kurz <groug@kaod.org>
>>>>>>> CC: anthony.perard@citrix.com
>>>>>>> CC: jgross@suse.com
>>>>>>> ---
>>>>>>> NB: The new macros have not been committed to Xen yet. Do not apply this
>>>>>>> patch until they do.
>>>>>>> ---
>>>>>>
>>>>>> Looking at your other series for the kernel part of this feature:
>>>>>>
>>>>>> https://lkml.org/lkml/2017/3/22/761
>>>>>>
>>>>>> I realize that the ring.h header from Xen also exists in the kernel tree... 
>>>>>>
>>>>>> Shouldn't all the code that can be used in both kernel and userspace go to a
>>>>>> header file under include/uapi in the kernel tree ? And then we would import
>>>>>> it under include/standard-headers/linux in the QEMU tree and we could keep it
>>>>>> in sync using scripts/update-linux-headers.sh.
>>>>>>
>>>>>> Cc'ing Paolo for insights.
>>>>>
>>>>> As Xen isn't part of the kernel we don't want that. You can use and/or
>>>>> build qemu with xen-9pfs backend support on an old Linux kernel without
>>>>> the related frontend.
>>>>
>>>> As long as the header changes rarely, I guess it's fine not to go
>>>> through update-linux-headers.sh.
>>>
>>> Very rarely, last time ring.h was changed was 2015, and to introduce a
>>> new macro (which we don't necessarily need in QEMU).
>>>
>>>
>>>>> OTOH I don't see the advantage of not using the headers from Xen. This
>>>>> is working for qdisk and pvusb backends and for all the Xen libraries.
>>>>> Do you expect the 9pfs backend to be used for a qemu version built
>>>>> against a Xen version not supporting that backend?
>>>
>>> Yes, I think that is entirely possible: Xen and QEMU versions can mix
>>> and match.
>>>
>>> Keeping in mind that the 9pfs backend has actually no build dependencies
>>> on Xen, except for these new ring.h macros, we have the following
>>> options:
>>>
>>> 1) we build the 9pfs backend only for Xen >= 4.9, because of the new
>>>    macros in ring.h that we need
>>
>> Right. You have sent 9pfs support patches for Xen tools. So obviously
>> you need a proper Xen version to use 9pfs. Why not build qemu against
>> it? Do you really expect a new Xen being used with an old qemu while
>> wanting to use new features? That makes no sense for me.
>  
> Tools support is needed to setup the frontend/backend connection as
> usual, but that's not a requirement for building the 9pfs backend. In
> fact, the backend doesn't need any tools support for it to work. The
> macro themselves are just a convenience - the backend would work just
> fine without them. Why restrict the QEMU build gratuitously?

You are duplicating a header without any real benefit I can see. This
is adding future work for keeping both versions of the header in sync.

In which scenario would you want qemu to support xen-9pfs without being
built against a Xen version supporting xen-9pfs?

I am not completely against copying the header, I just don't see an
advantage for any distro or user in doing it.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v4 1/8] xen: import ring.h from xen

[Stefano Stabellini]

On Mon, 27 Mar 2017, Juergen Gross wrote:
> On 24/03/17 18:37, Stefano Stabellini wrote:
> > On Fri, 24 Mar 2017, Juergen Gross wrote:
> >> On 23/03/17 19:22, Stefano Stabellini wrote:
> >>> On Thu, 23 Mar 2017, Paolo Bonzini wrote:
> >>>> On 23/03/2017 14:55, Juergen Gross wrote:
> >>>>> On 23/03/17 14:00, Greg Kurz wrote:
> >>>>>> On Mon, 20 Mar 2017 11:19:05 -0700
> >>>>>> Stefano Stabellini <sstabellini@kernel.org> wrote:
> >>>>>>
> >>>>>>> Do not use the ring.h header installed on the system. Instead, import
> >>>>>>> the header into the QEMU codebase. This avoids problems when QEMU is
> >>>>>>> built against a Xen version too old to provide all the ring macros.
> >>>>>>>
> >>>>>>> Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
> >>>>>>> Reviewed-by: Greg Kurz <groug@kaod.org>
> >>>>>>> CC: anthony.perard@citrix.com
> >>>>>>> CC: jgross@suse.com
> >>>>>>> ---
> >>>>>>> NB: The new macros have not been committed to Xen yet. Do not apply this
> >>>>>>> patch until they do.
> >>>>>>> ---
> >>>>>>
> >>>>>> Looking at your other series for the kernel part of this feature:
> >>>>>>
> >>>>>> https://lkml.org/lkml/2017/3/22/761
> >>>>>>
> >>>>>> I realize that the ring.h header from Xen also exists in the kernel tree... 
> >>>>>>
> >>>>>> Shouldn't all the code that can be used in both kernel and userspace go to a
> >>>>>> header file under include/uapi in the kernel tree ? And then we would import
> >>>>>> it under include/standard-headers/linux in the QEMU tree and we could keep it
> >>>>>> in sync using scripts/update-linux-headers.sh.
> >>>>>>
> >>>>>> Cc'ing Paolo for insights.
> >>>>>
> >>>>> As Xen isn't part of the kernel we don't want that. You can use and/or
> >>>>> build qemu with xen-9pfs backend support on an old Linux kernel without
> >>>>> the related frontend.
> >>>>
> >>>> As long as the header changes rarely, I guess it's fine not to go
> >>>> through update-linux-headers.sh.
> >>>
> >>> Very rarely, last time ring.h was changed was 2015, and to introduce a
> >>> new macro (which we don't necessarily need in QEMU).
> >>>
> >>>
> >>>>> OTOH I don't see the advantage of not using the headers from Xen. This
> >>>>> is working for qdisk and pvusb backends and for all the Xen libraries.
> >>>>> Do you expect the 9pfs backend to be used for a qemu version built
> >>>>> against a Xen version not supporting that backend?
> >>>
> >>> Yes, I think that is entirely possible: Xen and QEMU versions can mix
> >>> and match.
> >>>
> >>> Keeping in mind that the 9pfs backend has actually no build dependencies
> >>> on Xen, except for these new ring.h macros, we have the following
> >>> options:
> >>>
> >>> 1) we build the 9pfs backend only for Xen >= 4.9, because of the new
> >>>    macros in ring.h that we need
> >>
> >> Right. You have sent 9pfs support patches for Xen tools. So obviously
> >> you need a proper Xen version to use 9pfs. Why not build qemu against
> >> it? Do you really expect a new Xen being used with an old qemu while
> >> wanting to use new features? That makes no sense for me.
> >  
> > Tools support is needed to setup the frontend/backend connection as
> > usual, but that's not a requirement for building the 9pfs backend. In
> > fact, the backend doesn't need any tools support for it to work. The
> > macro themselves are just a convenience - the backend would work just
> > fine without them. Why restrict the QEMU build gratuitously?
> 
> You are duplicating a header without any real benefit I can see. This
> is adding future work for keeping both versions of the header in sync.
> 
> In which scenario would you want qemu to support xen-9pfs without being
> built against a Xen version supporting xen-9pfs?
> 
> I am not completely against copying the header, I just don't see an
> advantage for any distro or user in doing it.

I understand your point of view, and honestly it wouldn't be a problem
doing it the way you suggested either. However, I think that going
forward it will be less of a maintenance pain to keep ring.h in sync,
compared to maintaining a versioned build dependency between Xen and
QEMU for the compilation of one PV backend. We do have version checks
in QEMU for Xen compatibility, but not for PV backends or the xenpv
machine yet.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v4 1/8] xen: import ring.h from xen

[Juergen Gross]

On 28/03/17 00:48, Stefano Stabellini wrote:
> On Mon, 27 Mar 2017, Juergen Gross wrote:
>> On 24/03/17 18:37, Stefano Stabellini wrote:
>>> On Fri, 24 Mar 2017, Juergen Gross wrote:
>>>> On 23/03/17 19:22, Stefano Stabellini wrote:
>>>>> On Thu, 23 Mar 2017, Paolo Bonzini wrote:
>>>>>> On 23/03/2017 14:55, Juergen Gross wrote:
>>>>>>> On 23/03/17 14:00, Greg Kurz wrote:
>>>>>>>> On Mon, 20 Mar 2017 11:19:05 -0700
>>>>>>>> Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>>>>>>
>>>>>>>>> Do not use the ring.h header installed on the system. Instead, import
>>>>>>>>> the header into the QEMU codebase. This avoids problems when QEMU is
>>>>>>>>> built against a Xen version too old to provide all the ring macros.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
>>>>>>>>> Reviewed-by: Greg Kurz <groug@kaod.org>
>>>>>>>>> CC: anthony.perard@citrix.com
>>>>>>>>> CC: jgross@suse.com
>>>>>>>>> ---
>>>>>>>>> NB: The new macros have not been committed to Xen yet. Do not apply this
>>>>>>>>> patch until they do.
>>>>>>>>> ---
>>>>>>>>
>>>>>>>> Looking at your other series for the kernel part of this feature:
>>>>>>>>
>>>>>>>> https://lkml.org/lkml/2017/3/22/761
>>>>>>>>
>>>>>>>> I realize that the ring.h header from Xen also exists in the kernel tree... 
>>>>>>>>
>>>>>>>> Shouldn't all the code that can be used in both kernel and userspace go to a
>>>>>>>> header file under include/uapi in the kernel tree ? And then we would import
>>>>>>>> it under include/standard-headers/linux in the QEMU tree and we could keep it
>>>>>>>> in sync using scripts/update-linux-headers.sh.
>>>>>>>>
>>>>>>>> Cc'ing Paolo for insights.
>>>>>>>
>>>>>>> As Xen isn't part of the kernel we don't want that. You can use and/or
>>>>>>> build qemu with xen-9pfs backend support on an old Linux kernel without
>>>>>>> the related frontend.
>>>>>>
>>>>>> As long as the header changes rarely, I guess it's fine not to go
>>>>>> through update-linux-headers.sh.
>>>>>
>>>>> Very rarely, last time ring.h was changed was 2015, and to introduce a
>>>>> new macro (which we don't necessarily need in QEMU).
>>>>>
>>>>>
>>>>>>> OTOH I don't see the advantage of not using the headers from Xen. This
>>>>>>> is working for qdisk and pvusb backends and for all the Xen libraries.
>>>>>>> Do you expect the 9pfs backend to be used for a qemu version built
>>>>>>> against a Xen version not supporting that backend?
>>>>>
>>>>> Yes, I think that is entirely possible: Xen and QEMU versions can mix
>>>>> and match.
>>>>>
>>>>> Keeping in mind that the 9pfs backend has actually no build dependencies
>>>>> on Xen, except for these new ring.h macros, we have the following
>>>>> options:
>>>>>
>>>>> 1) we build the 9pfs backend only for Xen >= 4.9, because of the new
>>>>>    macros in ring.h that we need
>>>>
>>>> Right. You have sent 9pfs support patches for Xen tools. So obviously
>>>> you need a proper Xen version to use 9pfs. Why not build qemu against
>>>> it? Do you really expect a new Xen being used with an old qemu while
>>>> wanting to use new features? That makes no sense for me.
>>>  
>>> Tools support is needed to setup the frontend/backend connection as
>>> usual, but that's not a requirement for building the 9pfs backend. In
>>> fact, the backend doesn't need any tools support for it to work. The
>>> macro themselves are just a convenience - the backend would work just
>>> fine without them. Why restrict the QEMU build gratuitously?
>>
>> You are duplicating a header without any real benefit I can see. This
>> is adding future work for keeping both versions of the header in sync.
>>
>> In which scenario would you want qemu to support xen-9pfs without being
>> built against a Xen version supporting xen-9pfs?
>>
>> I am not completely against copying the header, I just don't see an
>> advantage for any distro or user in doing it.
> 
> I understand your point of view, and honestly it wouldn't be a problem
> doing it the way you suggested either. However, I think that going
> forward it will be less of a maintenance pain to keep ring.h in sync,
> compared to maintaining a versioned build dependency between Xen and
> QEMU for the compilation of one PV backend. We do have version checks
> in QEMU for Xen compatibility, but not for PV backends or the xenpv
> machine yet.

For the pvUSB backend I just used a mandatory macro from the header for
the #ifdef. The backend will signal support when it was defined during
build and will refuse initialization otherwise. Xen tools are able to
recoginze qemu support of the backend by looking into Xenstore.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v4 1/8] xen: import ring.h from xen

[Stefano Stabellini]

On Tue, 28 Mar 2017, Juergen Gross wrote:
> On 28/03/17 00:48, Stefano Stabellini wrote:
> > On Mon, 27 Mar 2017, Juergen Gross wrote:
> >> On 24/03/17 18:37, Stefano Stabellini wrote:
> >>> On Fri, 24 Mar 2017, Juergen Gross wrote:
> >>>> On 23/03/17 19:22, Stefano Stabellini wrote:
> >>>>> On Thu, 23 Mar 2017, Paolo Bonzini wrote:
> >>>>>> On 23/03/2017 14:55, Juergen Gross wrote:
> >>>>>>> On 23/03/17 14:00, Greg Kurz wrote:
> >>>>>>>> On Mon, 20 Mar 2017 11:19:05 -0700
> >>>>>>>> Stefano Stabellini <sstabellini@kernel.org> wrote:
> >>>>>>>>
> >>>>>>>>> Do not use the ring.h header installed on the system. Instead, import
> >>>>>>>>> the header into the QEMU codebase. This avoids problems when QEMU is
> >>>>>>>>> built against a Xen version too old to provide all the ring macros.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
> >>>>>>>>> Reviewed-by: Greg Kurz <groug@kaod.org>
> >>>>>>>>> CC: anthony.perard@citrix.com
> >>>>>>>>> CC: jgross@suse.com
> >>>>>>>>> ---
> >>>>>>>>> NB: The new macros have not been committed to Xen yet. Do not apply this
> >>>>>>>>> patch until they do.
> >>>>>>>>> ---
> >>>>>>>>
> >>>>>>>> Looking at your other series for the kernel part of this feature:
> >>>>>>>>
> >>>>>>>> https://lkml.org/lkml/2017/3/22/761
> >>>>>>>>
> >>>>>>>> I realize that the ring.h header from Xen also exists in the kernel tree... 
> >>>>>>>>
> >>>>>>>> Shouldn't all the code that can be used in both kernel and userspace go to a
> >>>>>>>> header file under include/uapi in the kernel tree ? And then we would import
> >>>>>>>> it under include/standard-headers/linux in the QEMU tree and we could keep it
> >>>>>>>> in sync using scripts/update-linux-headers.sh.
> >>>>>>>>
> >>>>>>>> Cc'ing Paolo for insights.
> >>>>>>>
> >>>>>>> As Xen isn't part of the kernel we don't want that. You can use and/or
> >>>>>>> build qemu with xen-9pfs backend support on an old Linux kernel without
> >>>>>>> the related frontend.
> >>>>>>
> >>>>>> As long as the header changes rarely, I guess it's fine not to go
> >>>>>> through update-linux-headers.sh.
> >>>>>
> >>>>> Very rarely, last time ring.h was changed was 2015, and to introduce a
> >>>>> new macro (which we don't necessarily need in QEMU).
> >>>>>
> >>>>>
> >>>>>>> OTOH I don't see the advantage of not using the headers from Xen. This
> >>>>>>> is working for qdisk and pvusb backends and for all the Xen libraries.
> >>>>>>> Do you expect the 9pfs backend to be used for a qemu version built
> >>>>>>> against a Xen version not supporting that backend?
> >>>>>
> >>>>> Yes, I think that is entirely possible: Xen and QEMU versions can mix
> >>>>> and match.
> >>>>>
> >>>>> Keeping in mind that the 9pfs backend has actually no build dependencies
> >>>>> on Xen, except for these new ring.h macros, we have the following
> >>>>> options:
> >>>>>
> >>>>> 1) we build the 9pfs backend only for Xen >= 4.9, because of the new
> >>>>>    macros in ring.h that we need
> >>>>
> >>>> Right. You have sent 9pfs support patches for Xen tools. So obviously
> >>>> you need a proper Xen version to use 9pfs. Why not build qemu against
> >>>> it? Do you really expect a new Xen being used with an old qemu while
> >>>> wanting to use new features? That makes no sense for me.
> >>>  
> >>> Tools support is needed to setup the frontend/backend connection as
> >>> usual, but that's not a requirement for building the 9pfs backend. In
> >>> fact, the backend doesn't need any tools support for it to work. The
> >>> macro themselves are just a convenience - the backend would work just
> >>> fine without them. Why restrict the QEMU build gratuitously?
> >>
> >> You are duplicating a header without any real benefit I can see. This
> >> is adding future work for keeping both versions of the header in sync.
> >>
> >> In which scenario would you want qemu to support xen-9pfs without being
> >> built against a Xen version supporting xen-9pfs?
> >>
> >> I am not completely against copying the header, I just don't see an
> >> advantage for any distro or user in doing it.
> > 
> > I understand your point of view, and honestly it wouldn't be a problem
> > doing it the way you suggested either. However, I think that going
> > forward it will be less of a maintenance pain to keep ring.h in sync,
> > compared to maintaining a versioned build dependency between Xen and
> > QEMU for the compilation of one PV backend. We do have version checks
> > in QEMU for Xen compatibility, but not for PV backends or the xenpv
> > machine yet.
> 
> For the pvUSB backend I just used a mandatory macro from the header for
> the #ifdef. The backend will signal support when it was defined during
> build and will refuse initialization otherwise. Xen tools are able to
> recoginze qemu support of the backend by looking into Xenstore.


What do you think of the following:

diff --git a/hw/9pfs/Makefile.objs b/hw/9pfs/Makefile.objs
index cab5e94..42530b8 100644
--- a/hw/9pfs/Makefile.objs
+++ b/hw/9pfs/Makefile.objs
@@ -5,6 +5,8 @@ common-obj-y += coth.o cofs.o codir.o cofile.o
 common-obj-y += coxattr.o 9p-synth.o
 common-obj-$(CONFIG_OPEN_BY_HANDLE) +=  9p-handle.o
 common-obj-y += 9p-proxy.o
-common-obj-$(CONFIG_XEN) += xen-9p-backend.o
+ifeq ($(shell test $(CONFIG_XEN_CTRL_INTERFACE_VERSION) -ge 40900; echo $$?),0)
+common-obj-y += xen-9p-backend.o
+endif
 
 obj-y += virtio-9p-device.o
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index c85f163..defcbff 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -583,7 +583,7 @@ void xen_be_register_common(void)
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
-#ifdef CONFIG_VIRTFS
+#if defined(CONFIG_VIRTFS) && CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900
     xen_be_register("9pfs", &xen_9pfs_ops);
 #endif
 #ifdef CONFIG_USB_LIBUSB

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v4 1/8] xen: import ring.h from xen

[Juergen Gross]

On 29/03/17 01:54, Stefano Stabellini wrote:
> On Tue, 28 Mar 2017, Juergen Gross wrote:
>> On 28/03/17 00:48, Stefano Stabellini wrote:
>>> On Mon, 27 Mar 2017, Juergen Gross wrote:
>>>> On 24/03/17 18:37, Stefano Stabellini wrote:
>>>>> On Fri, 24 Mar 2017, Juergen Gross wrote:
>>>>>> On 23/03/17 19:22, Stefano Stabellini wrote:
>>>>>>> On Thu, 23 Mar 2017, Paolo Bonzini wrote:
>>>>>>>> On 23/03/2017 14:55, Juergen Gross wrote:
>>>>>>>>> On 23/03/17 14:00, Greg Kurz wrote:
>>>>>>>>>> On Mon, 20 Mar 2017 11:19:05 -0700
>>>>>>>>>> Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Do not use the ring.h header installed on the system. Instead, import
>>>>>>>>>>> the header into the QEMU codebase. This avoids problems when QEMU is
>>>>>>>>>>> built against a Xen version too old to provide all the ring macros.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
>>>>>>>>>>> Reviewed-by: Greg Kurz <groug@kaod.org>
>>>>>>>>>>> CC: anthony.perard@citrix.com
>>>>>>>>>>> CC: jgross@suse.com
>>>>>>>>>>> ---
>>>>>>>>>>> NB: The new macros have not been committed to Xen yet. Do not apply this
>>>>>>>>>>> patch until they do.
>>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> Looking at your other series for the kernel part of this feature:
>>>>>>>>>>
>>>>>>>>>> https://lkml.org/lkml/2017/3/22/761
>>>>>>>>>>
>>>>>>>>>> I realize that the ring.h header from Xen also exists in the kernel tree... 
>>>>>>>>>>
>>>>>>>>>> Shouldn't all the code that can be used in both kernel and userspace go to a
>>>>>>>>>> header file under include/uapi in the kernel tree ? And then we would import
>>>>>>>>>> it under include/standard-headers/linux in the QEMU tree and we could keep it
>>>>>>>>>> in sync using scripts/update-linux-headers.sh.
>>>>>>>>>>
>>>>>>>>>> Cc'ing Paolo for insights.
>>>>>>>>>
>>>>>>>>> As Xen isn't part of the kernel we don't want that. You can use and/or
>>>>>>>>> build qemu with xen-9pfs backend support on an old Linux kernel without
>>>>>>>>> the related frontend.
>>>>>>>>
>>>>>>>> As long as the header changes rarely, I guess it's fine not to go
>>>>>>>> through update-linux-headers.sh.
>>>>>>>
>>>>>>> Very rarely, last time ring.h was changed was 2015, and to introduce a
>>>>>>> new macro (which we don't necessarily need in QEMU).
>>>>>>>
>>>>>>>
>>>>>>>>> OTOH I don't see the advantage of not using the headers from Xen. This
>>>>>>>>> is working for qdisk and pvusb backends and for all the Xen libraries.
>>>>>>>>> Do you expect the 9pfs backend to be used for a qemu version built
>>>>>>>>> against a Xen version not supporting that backend?
>>>>>>>
>>>>>>> Yes, I think that is entirely possible: Xen and QEMU versions can mix
>>>>>>> and match.
>>>>>>>
>>>>>>> Keeping in mind that the 9pfs backend has actually no build dependencies
>>>>>>> on Xen, except for these new ring.h macros, we have the following
>>>>>>> options:
>>>>>>>
>>>>>>> 1) we build the 9pfs backend only for Xen >= 4.9, because of the new
>>>>>>>    macros in ring.h that we need
>>>>>>
>>>>>> Right. You have sent 9pfs support patches for Xen tools. So obviously
>>>>>> you need a proper Xen version to use 9pfs. Why not build qemu against
>>>>>> it? Do you really expect a new Xen being used with an old qemu while
>>>>>> wanting to use new features? That makes no sense for me.
>>>>>  
>>>>> Tools support is needed to setup the frontend/backend connection as
>>>>> usual, but that's not a requirement for building the 9pfs backend. In
>>>>> fact, the backend doesn't need any tools support for it to work. The
>>>>> macro themselves are just a convenience - the backend would work just
>>>>> fine without them. Why restrict the QEMU build gratuitously?
>>>>
>>>> You are duplicating a header without any real benefit I can see. This
>>>> is adding future work for keeping both versions of the header in sync.
>>>>
>>>> In which scenario would you want qemu to support xen-9pfs without being
>>>> built against a Xen version supporting xen-9pfs?
>>>>
>>>> I am not completely against copying the header, I just don't see an
>>>> advantage for any distro or user in doing it.
>>>
>>> I understand your point of view, and honestly it wouldn't be a problem
>>> doing it the way you suggested either. However, I think that going
>>> forward it will be less of a maintenance pain to keep ring.h in sync,
>>> compared to maintaining a versioned build dependency between Xen and
>>> QEMU for the compilation of one PV backend. We do have version checks
>>> in QEMU for Xen compatibility, but not for PV backends or the xenpv
>>> machine yet.
>>
>> For the pvUSB backend I just used a mandatory macro from the header for
>> the #ifdef. The backend will signal support when it was defined during
>> build and will refuse initialization otherwise. Xen tools are able to
>> recoginze qemu support of the backend by looking into Xenstore.
> 
> 
> What do you think of the following:
> 
> diff --git a/hw/9pfs/Makefile.objs b/hw/9pfs/Makefile.objs
> index cab5e94..42530b8 100644
> --- a/hw/9pfs/Makefile.objs
> +++ b/hw/9pfs/Makefile.objs
> @@ -5,6 +5,8 @@ common-obj-y += coth.o cofs.o codir.o cofile.o
>  common-obj-y += coxattr.o 9p-synth.o
>  common-obj-$(CONFIG_OPEN_BY_HANDLE) +=  9p-handle.o
>  common-obj-y += 9p-proxy.o
> -common-obj-$(CONFIG_XEN) += xen-9p-backend.o
> +ifeq ($(shell test $(CONFIG_XEN_CTRL_INTERFACE_VERSION) -ge 40900; echo $$?),0)
> +common-obj-y += xen-9p-backend.o
> +endif

What about:

XEN_9PFS = $(shell test $(CONFIG_XEN_CTRL_INTERFACE_VERSION) -ge 40900
&& echo y)
common-obj-$(XEN_9PFS) += xen-9p-backend.o


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v4 1/8] xen: import ring.h from xen

[Paolo Bonzini]

On 29/03/2017 01:54, Stefano Stabellini wrote:
>>> I understand your point of view, and honestly it wouldn't be a problem
>>> doing it the way you suggested either. However, I think that going
>>> forward it will be less of a maintenance pain to keep ring.h in sync,
>>> compared to maintaining a versioned build dependency between Xen and
>>> QEMU for the compilation of one PV backend. We do have version checks
>>> in QEMU for Xen compatibility, but not for PV backends or the xenpv
>>> machine yet.
>> For the pvUSB backend I just used a mandatory macro from the header for
>> the #ifdef. The backend will signal support when it was defined during
>> build and will refuse initialization otherwise. Xen tools are able to
>> recoginze qemu support of the backend by looking into Xenstore.
> 
> What do you think of the following:

Let's just copy the header...

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v4 1/8] xen: import ring.h from xen

[Stefano Stabellini]

On Wed, 29 Mar 2017, Paolo Bonzini wrote:
> On 29/03/2017 01:54, Stefano Stabellini wrote:
> >>> I understand your point of view, and honestly it wouldn't be a problem
> >>> doing it the way you suggested either. However, I think that going
> >>> forward it will be less of a maintenance pain to keep ring.h in sync,
> >>> compared to maintaining a versioned build dependency between Xen and
> >>> QEMU for the compilation of one PV backend. We do have version checks
> >>> in QEMU for Xen compatibility, but not for PV backends or the xenpv
> >>> machine yet.
> >> For the pvUSB backend I just used a mandatory macro from the header for
> >> the #ifdef. The backend will signal support when it was defined during
> >> build and will refuse initialization otherwise. Xen tools are able to
> >> recoginze qemu support of the backend by looking into Xenstore.
> > 
> > What do you think of the following:
> 
> Let's just copy the header...

It's settled.

Thanks,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel