Re: [PATCH V2 23/23] [RFC] libxl: Add support for virtio-disk configuration

2020-11-13 Thread Oleksandr 



On 11.11.20 06:28, Wei Chen wrote:

Hi Oleksandr,


Hi Wei



An example of domain configuration (two disks are assigned to the guest,
the latter is in readonly mode):

vdisk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3;ro:/dev/mmcblk1p3' ]


Can we keep use the same 'disk' parameter for virtio-disk, but add an option

like

   "model=virtio-disk"?
For example:
disk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3,model=virtio-disk' ]
Just like what Xen has done for x86 virtio-net.

I think, this needs an additional investigation. In general I agree with
you that it would be nice to reuse existing 'disk' parameter somehow
rather than introducing new one
for the same purpose (to handle virtual block device(s)).


One note, although both are used for the same purpose they are different
in at least one important option.

For example:
1. disk = [ 'backend=DomD, phy:/dev/mmcblk0p3, xvda1' ]
2. vdisk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3' ]
As you can see existing "disk" parameter contains xvda1, this means that
a new device /dev/xvda1 will appear at the guest side, but "vdisk"
doesn't contain anything similar. So with Xen PV driver (xen-blkfront)

Yes, I understand your concerns. But I think specifying a device name
for virtio disk is not a mandatory requirement. Even if we're using physical
disks on bare metal machine, we can't guarantee slot#1 disk is always 'sda'.
So most modern OS are prefer to use blkid to mount filesystem.


we are able to configure a device name, but with VirtIO solution
(virtio-blk) we aren't (at least I don't know how exactly).


Just my understanding, not exactly accurate:
The virtio-blk could not get VDEV information for a bus like Xen-bus. So the 
disk
ID is allocated dynamically in bus probe progress. The first probed disk will 
get
ID 'a'. And then the ID keeps increasing. If we want to specify the disk ID for 
virtio
disk, one possible way to do this is to construct a reasonable position on bus
(fdt node position of virtio mmio device, PCI Function ID of virtio pci block) 
for
virtio disk. But it is not always successful, we can't skip 'vda' to specify a 
virtio
disk as 'vdb'.
Thank you for the explanation. I got your point regarding using the same 
disk parameter and I think it makes sense. Now I am focusing on IOREQ 
transport to be available on Arm, and after that (I hope)

I will be able to return to virtio stuff.

--
Regards,

Oleksandr Tyshchenko

RE: [PATCH V2 23/23] [RFC] libxl: Add support for virtio-disk configuration

2020-11-10 Thread Wei Chen 
Hi Oleksandr,

> -Original Message-
> From: Oleksandr 
> Sent: 2020年11月11日 8:53
> To: Wei Chen ; xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Ian Jackson
> ; Wei Liu ; Anthony PERARD
> ; Julien Grall ; Stefano Stabellini
> 
> Subject: Re: [PATCH V2 23/23] [RFC] libxl: Add support for virtio-disk
> configuration
> 
> 
> On 09.11.20 08:45, Wei Chen wrote:
> > Hi Oleksandr,
> 
> Hi Wei
> 
> 
> >
> >> -Original Message-
> >> From: Xen-devel  On Behalf Of
> >> Oleksandr Tyshchenko
> >> Sent: 2020年10月16日 0:45
> >> To: xen-devel@lists.xenproject.org
> >> Cc: Oleksandr Tyshchenko ; Ian Jackson
> >> ; Wei Liu ; Anthony PERARD
> >> ; Julien Grall ; Stefano
> Stabellini
> >> 
> >> Subject: [PATCH V2 23/23] [RFC] libxl: Add support for virtio-disk
> configuration
> >>
> >> From: Oleksandr Tyshchenko 
> >>
> >> This patch adds basic support for configuring and assisting virtio-disk
> >> backend (emualator) which is intended to run out of Qemu and could be run
> >> in any domain.
> >>
> >> Xenstore was chosen as a communication interface for the emulator running
> >> in non-toolstack domain to be able to get configuration either by reading
> >> Xenstore directly or by receiving command line parameters (an updated 'xl
> devd'
> >> running in the same domain would read Xenstore beforehand and call
> backend
> >> executable with the required arguments).
> >>
> >> An example of domain configuration (two disks are assigned to the guest,
> >> the latter is in readonly mode):
> >>
> >> vdisk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3;ro:/dev/mmcblk1p3' ]
> >>
> > Can we keep use the same 'disk' parameter for virtio-disk, but add an option
> like
> >   "model=virtio-disk"?
> > For example:
> > disk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3,model=virtio-disk' ]
> > Just like what Xen has done for x86 virtio-net.
> 
> I think, this needs an additional investigation. In general I agree with
> you that it would be nice to reuse existing 'disk' parameter somehow
> rather than introducing new one
> for the same purpose (to handle virtual block device(s)).
> 
> 
> One note, although both are used for the same purpose they are different
> in at least one important option.
> 
> For example:
> 1. disk = [ 'backend=DomD, phy:/dev/mmcblk0p3, xvda1' ]
> 2. vdisk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3' ]
> As you can see existing "disk" parameter contains xvda1, this means that
> a new device /dev/xvda1 will appear at the guest side, but "vdisk"
> doesn't contain anything similar. So with Xen PV driver (xen-blkfront)

Yes, I understand your concerns. But I think specifying a device name
for virtio disk is not a mandatory requirement. Even if we're using physical
disks on bare metal machine, we can't guarantee slot#1 disk is always 'sda'.
So most modern OS are prefer to use blkid to mount filesystem.

> we are able to configure a device name, but with VirtIO solution
> (virtio-blk) we aren't (at least I don't know how exactly).
> 

Just my understanding, not exactly accurate:
The virtio-blk could not get VDEV information for a bus like Xen-bus. So the 
disk
ID is allocated dynamically in bus probe progress. The first probed disk will 
get
ID 'a'. And then the ID keeps increasing. If we want to specify the disk ID for 
virtio
disk, one possible way to do this is to construct a reasonable position on bus
(fdt node position of virtio mmio device, PCI Function ID of virtio pci block) 
for
virtio disk. But it is not always successful, we can't skip 'vda' to specify a 
virtio
disk as 'vdb'.

Regards,
Wei Chen
> 
> 
> 
> 
> --
> Regards,
> 
> Oleksandr Tyshchenko

Re: [PATCH V2 23/23] [RFC] libxl: Add support for virtio-disk configuration

2020-11-10 Thread Oleksandr 



On 09.11.20 08:45, Wei Chen wrote:

Hi Oleksandr,


Hi Wei





-Original Message-
From: Xen-devel  On Behalf Of
Oleksandr Tyshchenko
Sent: 2020年10月16日 0:45
To: xen-devel@lists.xenproject.org
Cc: Oleksandr Tyshchenko ; Ian Jackson
; Wei Liu ; Anthony PERARD
; Julien Grall ; Stefano Stabellini

Subject: [PATCH V2 23/23] [RFC] libxl: Add support for virtio-disk configuration

From: Oleksandr Tyshchenko 

This patch adds basic support for configuring and assisting virtio-disk
backend (emualator) which is intended to run out of Qemu and could be run
in any domain.

Xenstore was chosen as a communication interface for the emulator running
in non-toolstack domain to be able to get configuration either by reading
Xenstore directly or by receiving command line parameters (an updated 'xl devd'
running in the same domain would read Xenstore beforehand and call backend
executable with the required arguments).

An example of domain configuration (two disks are assigned to the guest,
the latter is in readonly mode):

vdisk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3;ro:/dev/mmcblk1p3' ]


Can we keep use the same 'disk' parameter for virtio-disk, but add an option 
like
  "model=virtio-disk"?
For example:
disk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3,model=virtio-disk' ]
Just like what Xen has done for x86 virtio-net.


I think, this needs an additional investigation. In general I agree with 
you that it would be nice to reuse existing 'disk' parameter somehow 
rather than introducing new one

for the same purpose (to handle virtual block device(s)).


One note, although both are used for the same purpose they are different 
in at least one important option.


For example:
1. disk = [ 'backend=DomD, phy:/dev/mmcblk0p3, xvda1' ]
2. vdisk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3' ]
As you can see existing "disk" parameter contains xvda1, this means that 
a new device /dev/xvda1 will appear at the guest side, but "vdisk" 
doesn't contain anything similar. So with Xen PV driver (xen-blkfront) 
we are able to configure a device name, but with VirtIO solution 
(virtio-blk) we aren't (at least I don't know how exactly).






--
Regards,

Oleksandr Tyshchenko

RE: [PATCH V2 23/23] [RFC] libxl: Add support for virtio-disk configuration

2020-11-08 Thread Wei Chen 
Hi Oleksandr,

> -Original Message-
> From: Xen-devel  On Behalf Of
> Oleksandr Tyshchenko
> Sent: 2020年10月16日 0:45
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Ian Jackson
> ; Wei Liu ; Anthony PERARD
> ; Julien Grall ; Stefano Stabellini
> 
> Subject: [PATCH V2 23/23] [RFC] libxl: Add support for virtio-disk 
> configuration
> 
> From: Oleksandr Tyshchenko 
> 
> This patch adds basic support for configuring and assisting virtio-disk
> backend (emualator) which is intended to run out of Qemu and could be run
> in any domain.
> 
> Xenstore was chosen as a communication interface for the emulator running
> in non-toolstack domain to be able to get configuration either by reading
> Xenstore directly or by receiving command line parameters (an updated 'xl 
> devd'
> running in the same domain would read Xenstore beforehand and call backend
> executable with the required arguments).
> 
> An example of domain configuration (two disks are assigned to the guest,
> the latter is in readonly mode):
> 
> vdisk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3;ro:/dev/mmcblk1p3' ]
> 

Can we keep use the same 'disk' parameter for virtio-disk, but add an option 
like
 "model=virtio-disk"?
For example:
disk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3,model=virtio-disk' ]
Just like what Xen has done for x86 virtio-net.

> Where per-disk Xenstore entries are:
> - filename and readonly flag (configured via "vdisk" property)
> - base and irq (allocated dynamically)
> 
> Besides handling 'visible' params described in configuration file,
> patch also allocates virtio-mmio specific ones for each device and
> writes them into Xenstore. virtio-mmio params (irq and base) are
> unique per guest domain, they allocated at the domain creation time
> and passed through to the emulator. Each VirtIO device has at least
> one pair of these params.
> 
> TODO:
> 1. An extra "virtio" property could be removed.
> 2. Update documentation.
> 
> Signed-off-by: Oleksandr Tyshchenko 
> 
> ---
> Changes RFC -> V1:
>- no changes
> 
> Changes V1 -> V2:
>- rebase according to the new location of libxl_virtio_disk.c
> 
> Please note, there is a real concern about VirtIO interrupts allocation.
> Just copy here what Stefano said in RFC thread.
> 
> So, if we end up allocating let's say 6 virtio interrupts for a domain,
> the chance of a clash with a physical interrupt of a passthrough device is 
> real.
> 
> I am not entirely sure how to solve it, but these are a few ideas:
> - choosing virtio interrupts that are less likely to conflict (maybe > 1000)
> - make the virtio irq (optionally) configurable so that a user could
>   override the default irq and specify one that doesn't conflict
> - implementing support for virq != pirq (even the xl interface doesn't
>   allow to specify the virq number for passthrough devices, see "irqs")
> 
> ---
>  tools/libs/light/Makefile |   1 +
>  tools/libs/light/libxl_arm.c  |  56 ---
>  tools/libs/light/libxl_create.c   |   1 +
>  tools/libs/light/libxl_internal.h |   1 +
>  tools/libs/light/libxl_types.idl  |  15 
>  tools/libs/light/libxl_types_internal.idl |   1 +
>  tools/libs/light/libxl_virtio_disk.c  | 109 
>  tools/xl/Makefile |   2 +-
>  tools/xl/xl.h |   3 +
>  tools/xl/xl_cmdtable.c|  15 
>  tools/xl/xl_parse.c   | 115 
> ++
>  tools/xl/xl_virtio_disk.c |  46 
>  12 files changed, 354 insertions(+), 11 deletions(-)
>  create mode 100644 tools/libs/light/libxl_virtio_disk.c
>  create mode 100644 tools/xl/xl_virtio_disk.c
> 
> diff --git a/tools/libs/light/Makefile b/tools/libs/light/Makefile
> index f58a321..2ee388a 100644
> --- a/tools/libs/light/Makefile
> +++ b/tools/libs/light/Makefile
> @@ -115,6 +115,7 @@ SRCS-y += libxl_genid.c
>  SRCS-y += _libxl_types.c
>  SRCS-y += libxl_flask.c
>  SRCS-y += _libxl_types_internal.c
> +SRCS-y += libxl_virtio_disk.c
> 
>  ifeq ($(CONFIG_LIBNL),y)
>  CFLAGS_LIBXL += $(LIBNL3_CFLAGS)
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index 588ee5a..9eb3022 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -8,6 +8,12 @@
>  #include 
>  #include 
> 
> +#ifndef container_of
> +#define container_of(ptr, type, member) ({   \
> +typeof( ((type *)0)->member ) *__mptr = (ptr);   \
> +(type *)( (char *)__mptr - offseto

[PATCH V2 23/23] [RFC] libxl: Add support for virtio-disk configuration

2020-10-15 Thread Oleksandr Tyshchenko 
From: Oleksandr Tyshchenko 

This patch adds basic support for configuring and assisting virtio-disk
backend (emualator) which is intended to run out of Qemu and could be run
in any domain.

Xenstore was chosen as a communication interface for the emulator running
in non-toolstack domain to be able to get configuration either by reading
Xenstore directly or by receiving command line parameters (an updated 'xl devd'
running in the same domain would read Xenstore beforehand and call backend
executable with the required arguments).

An example of domain configuration (two disks are assigned to the guest,
the latter is in readonly mode):

vdisk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3;ro:/dev/mmcblk1p3' ]

Where per-disk Xenstore entries are:
- filename and readonly flag (configured via "vdisk" property)
- base and irq (allocated dynamically)

Besides handling 'visible' params described in configuration file,
patch also allocates virtio-mmio specific ones for each device and
writes them into Xenstore. virtio-mmio params (irq and base) are
unique per guest domain, they allocated at the domain creation time
and passed through to the emulator. Each VirtIO device has at least
one pair of these params.

TODO:
1. An extra "virtio" property could be removed.
2. Update documentation.

Signed-off-by: Oleksandr Tyshchenko 

---
Changes RFC -> V1:
   - no changes

Changes V1 -> V2:
   - rebase according to the new location of libxl_virtio_disk.c

Please note, there is a real concern about VirtIO interrupts allocation.
Just copy here what Stefano said in RFC thread.

So, if we end up allocating let's say 6 virtio interrupts for a domain,
the chance of a clash with a physical interrupt of a passthrough device is real.

I am not entirely sure how to solve it, but these are a few ideas:
- choosing virtio interrupts that are less likely to conflict (maybe > 1000)
- make the virtio irq (optionally) configurable so that a user could
  override the default irq and specify one that doesn't conflict
- implementing support for virq != pirq (even the xl interface doesn't
  allow to specify the virq number for passthrough devices, see "irqs")

---
 tools/libs/light/Makefile |   1 +
 tools/libs/light/libxl_arm.c  |  56 ---
 tools/libs/light/libxl_create.c   |   1 +
 tools/libs/light/libxl_internal.h |   1 +
 tools/libs/light/libxl_types.idl  |  15 
 tools/libs/light/libxl_types_internal.idl |   1 +
 tools/libs/light/libxl_virtio_disk.c  | 109 
 tools/xl/Makefile |   2 +-
 tools/xl/xl.h |   3 +
 tools/xl/xl_cmdtable.c|  15 
 tools/xl/xl_parse.c   | 115 ++
 tools/xl/xl_virtio_disk.c |  46 
 12 files changed, 354 insertions(+), 11 deletions(-)
 create mode 100644 tools/libs/light/libxl_virtio_disk.c
 create mode 100644 tools/xl/xl_virtio_disk.c

diff --git a/tools/libs/light/Makefile b/tools/libs/light/Makefile
index f58a321..2ee388a 100644
--- a/tools/libs/light/Makefile
+++ b/tools/libs/light/Makefile
@@ -115,6 +115,7 @@ SRCS-y += libxl_genid.c
 SRCS-y += _libxl_types.c
 SRCS-y += libxl_flask.c
 SRCS-y += _libxl_types_internal.c
+SRCS-y += libxl_virtio_disk.c
 
 ifeq ($(CONFIG_LIBNL),y)
 CFLAGS_LIBXL += $(LIBNL3_CFLAGS)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 588ee5a..9eb3022 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -8,6 +8,12 @@
 #include 
 #include 
 
+#ifndef container_of
+#define container_of(ptr, type, member) ({ \
+typeof( ((type *)0)->member ) *__mptr = (ptr); \
+(type *)( (char *)__mptr - offsetof(type,member) );})
+#endif
+
 static const char *gicv_to_string(libxl_gic_version gic_version)
 {
 switch (gic_version) {
@@ -39,14 +45,32 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
 vuart_enabled = true;
 }
 
-/*
- * XXX: Handle properly virtio
- * A proper solution would be the toolstack to allocate the interrupts
- * used by each virtio backend and let the backend now which one is used
- */
 if (libxl_defbool_val(d_config->b_info.arch_arm.virtio)) {
-nr_spis += (GUEST_VIRTIO_MMIO_SPI - 32) + 1;
+uint64_t virtio_base;
+libxl_device_virtio_disk *virtio_disk;
+
+virtio_base = GUEST_VIRTIO_MMIO_BASE;
 virtio_irq = GUEST_VIRTIO_MMIO_SPI;
+
+if (!d_config->num_virtio_disks) {
+LOG(ERROR, "Virtio is enabled, but no Virtio devices present\n");
+return ERROR_FAIL;
+}
+virtio_disk = _config->virtio_disks[0];
+
+for (i = 0; i < virtio_disk->num_disks; i++) {
+virtio_disk->disks[i].base = virtio_base;
+virtio_disk->disks[i].irq = virtio_irq;
+
+LOG(DEBUG, "Allocate Virtio MMIO params: IRQ %u BASE