KVM Development List

Cornelia Huck | 7 Aug 2012 16:52

[RFC PATCH 0/4] s390: virtio-ccw guest kernel support.

Hi,

the following patches are for Linux running as a guest under a
host with virtio-ccw support.

Patch 1 makes the kvm_virtio driver exit gracefully if the page
containing s390-virtio information it expects is not present; it
could probably go in seperately from the other patches.

Patch 2 exports a needed interface.

Patch 3 adds a driver handling virtio-ccw devices. The virtual
subchannels have ccw devices with a special CU id this driver
matches for. The virtio_ccw driver handles configuration and
operation via the special new channel commands.

Patch 4 is a split out of common code.

Cornelia Huck (4):
  s390/kvm: Handle hosts not supporting s390-virtio.
  s390: Add a mechanism to get the subchannel id.
  s390/kvm: Add a channel I/O based virtio transport driver.
  s390/kvm: Split out early console code.

 arch/s390/include/asm/ccwdev.h  |   5 +
 arch/s390/include/asm/irq.h     |   1 +
 arch/s390/kernel/irq.c          |   1 +
 drivers/s390/cio/device_ops.c   |  10 +
 drivers/s390/kvm/Makefile       |   2 +-
 drivers/s390/kvm/early_printk.c |  42 +++

(Continue reading)

headers

Cornelia Huck | 7 Aug 2012 16:52

[PATCH 1/4] s390/kvm: Handle hosts not supporting s390-virtio.

Running under a kvm host does not necessarily imply the presence of
a page mapped above the main memory with the virtio information;
however, the code includes a hard coded access to that page.

Instead, check for the presence of the page and exit gracefully
before we hit an addressing exception if it does not exist.

Signed-off-by: Cornelia Huck <cornelia.huck <at> de.ibm.com>
---
 drivers/s390/kvm/kvm_virtio.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/s390/kvm/kvm_virtio.c b/drivers/s390/kvm/kvm_virtio.c
index 47cccd5..408447c 100644
--- a/drivers/s390/kvm/kvm_virtio.c
+++ b/drivers/s390/kvm/kvm_virtio.c
 <at>  <at>  -418,6 +418,21  <at>  <at>  static void kvm_extint_handler(struct ext_code ext_code,
 	}
 }

+static int __init test_devices_support(void)
+{
+	int ccode = -EIO;
+
+	asm volatile(
+		"0:	cli	0(%1),0\n"
+		"	ipm	%0\n"
+		"	srl	%0,28\n"
+		"1:\n"
+		EX_TABLE(0b,1b)

(Continue reading)

headers

Avi Kivity | 9 Aug 2012 12:03

Re: [PATCH 1/4] s390/kvm: Handle hosts not supporting s390-virtio.

On 08/07/2012 05:52 PM, Cornelia Huck wrote:
> Running under a kvm host does not necessarily imply the presence of
> a page mapped above the main memory with the virtio information;
> however, the code includes a hard coded access to that page.
> 
> Instead, check for the presence of the page and exit gracefully
> before we hit an addressing exception if it does not exist.
> 
>  /*
>   * Init function for virtio
>   * devices are in a single page above top of "normal" mem
>  <at>  <at>  -443,6 +458,12  <at>  <at>  static int __init kvm_devices_init(void)
>  	}
>  
>  	kvm_devices = (void *) real_memory_size;
> +	if (test_devices_support() < 0) {
> +		vmem_remove_mapping(real_memory_size, PAGE_SIZE);
> +		root_device_unregister(kvm_root);
> +		/* No error. */
> +		return 0;
> +	}
>  

Cleaner to defer root_device_register() until after the mapping has been
verified.

--

-- 
error compiling committee.c: too many arguments to function

(Continue reading)

headers

Cornelia Huck | 9 Aug 2012 12:41

Re: [PATCH 1/4] s390/kvm: Handle hosts not supporting s390-virtio.

On Thu, 09 Aug 2012 13:03:57 +0300
Avi Kivity <avi <at> redhat.com> wrote:

> On 08/07/2012 05:52 PM, Cornelia Huck wrote:
> > Running under a kvm host does not necessarily imply the presence of
> > a page mapped above the main memory with the virtio information;
> > however, the code includes a hard coded access to that page.
> > 
> > Instead, check for the presence of the page and exit gracefully
> > before we hit an addressing exception if it does not exist.
> > 
> >  /*
> >   * Init function for virtio
> >   * devices are in a single page above top of "normal" mem
> >  <at>  <at>  -443,6 +458,12  <at>  <at>  static int __init kvm_devices_init(void)
> >  	}
> >  
> >  	kvm_devices = (void *) real_memory_size;
> > +	if (test_devices_support() < 0) {
> > +		vmem_remove_mapping(real_memory_size, PAGE_SIZE);
> > +		root_device_unregister(kvm_root);
> > +		/* No error. */
> > +		return 0;
> > +	}
> >  
> 
> Cleaner to defer root_device_register() until after the mapping has been
> verified.

OK, will reorder.

(Continue reading)

headers

Heiko Carstens | 10 Aug 2012 10:42

Re: [PATCH 1/4] s390/kvm: Handle hosts not supporting s390-virtio.

On Thu, Aug 09, 2012 at 12:41:57PM +0200, Cornelia Huck wrote:
> On Thu, 09 Aug 2012 13:03:57 +0300
> Avi Kivity <avi <at> redhat.com> wrote:
> 
> > On 08/07/2012 05:52 PM, Cornelia Huck wrote:
> > > Running under a kvm host does not necessarily imply the presence of
> > > a page mapped above the main memory with the virtio information;
> > > however, the code includes a hard coded access to that page.
> > > 
> > > Instead, check for the presence of the page and exit gracefully
> > > before we hit an addressing exception if it does not exist.
> > > 
> > >  /*
> > >   * Init function for virtio
> > >   * devices are in a single page above top of "normal" mem
> > >  <at>  <at>  -443,6 +458,12  <at>  <at>  static int __init kvm_devices_init(void)
> > >  	}
> > >  
> > >  	kvm_devices = (void *) real_memory_size;
> > > +	if (test_devices_support() < 0) {
> > > +		vmem_remove_mapping(real_memory_size, PAGE_SIZE);
> > > +		root_device_unregister(kvm_root);
> > > +		/* No error. */
> > > +		return 0;
> > > +	}
> > >  
> > 
> > Cleaner to defer root_device_register() until after the mapping has been
> > verified.
>

(Continue reading)

headers

Cornelia Huck | 10 Aug 2012 13:03

Re: [PATCH 1/4] s390/kvm: Handle hosts not supporting s390-virtio.

On Fri, 10 Aug 2012 10:42:48 +0200
Heiko Carstens <heiko.carstens <at> de.ibm.com> wrote:

> On Thu, Aug 09, 2012 at 12:41:57PM +0200, Cornelia Huck wrote:
> > On Thu, 09 Aug 2012 13:03:57 +0300
> > Avi Kivity <avi <at> redhat.com> wrote:
> > 
> > > On 08/07/2012 05:52 PM, Cornelia Huck wrote:
> > > > Running under a kvm host does not necessarily imply the presence of
> > > > a page mapped above the main memory with the virtio information;
> > > > however, the code includes a hard coded access to that page.
> > > > 
> > > > Instead, check for the presence of the page and exit gracefully
> > > > before we hit an addressing exception if it does not exist.
> > > > 
> > > >  /*
> > > >   * Init function for virtio
> > > >   * devices are in a single page above top of "normal" mem
> > > >  <at>  <at>  -443,6 +458,12  <at>  <at>  static int __init kvm_devices_init(void)
> > > >  	}
> > > >  
> > > >  	kvm_devices = (void *) real_memory_size;
> > > > +	if (test_devices_support() < 0) {
> > > > +		vmem_remove_mapping(real_memory_size, PAGE_SIZE);
> > > > +		root_device_unregister(kvm_root);
> > > > +		/* No error. */
> > > > +		return 0;
> > > > +	}
> > > >  
> > >

(Continue reading)

headers

Alexander Graf | 10 Aug 2012 01:09

Re: [PATCH 1/4] s390/kvm: Handle hosts not supporting s390-virtio.


On 07.08.2012, at 16:52, Cornelia Huck wrote:

> Running under a kvm host does not necessarily imply the presence of
> a page mapped above the main memory with the virtio information;
> however, the code includes a hard coded access to that page.
> 
> Instead, check for the presence of the page and exit gracefully
> before we hit an addressing exception if it does not exist.
> 
> Signed-off-by: Cornelia Huck <cornelia.huck <at> de.ibm.com>
> ---
> drivers/s390/kvm/kvm_virtio.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/s390/kvm/kvm_virtio.c b/drivers/s390/kvm/kvm_virtio.c
> index 47cccd5..408447c 100644
> --- a/drivers/s390/kvm/kvm_virtio.c
> +++ b/drivers/s390/kvm/kvm_virtio.c
>  <at>  <at>  -418,6 +418,21  <at>  <at>  static void kvm_extint_handler(struct ext_code ext_code,
> 	}
> }
> 
> +static int __init test_devices_support(void)

Today we know what this function does, but the next person running into it has no clue. Maybe add a nice
description here that you're trying to access memory above ram? (is this even what you're doing here? my
s390 asm is slightly rusty) :)

Alex

(Continue reading)

headers

Cornelia Huck | 10 Aug 2012 09:45

Re: [PATCH 1/4] s390/kvm: Handle hosts not supporting s390-virtio.

On Fri, 10 Aug 2012 01:09:15 +0200
Alexander Graf <agraf <at> suse.de> wrote:

> 
> On 07.08.2012, at 16:52, Cornelia Huck wrote:
> 
> > Running under a kvm host does not necessarily imply the presence of
> > a page mapped above the main memory with the virtio information;
> > however, the code includes a hard coded access to that page.
> > 
> > Instead, check for the presence of the page and exit gracefully
> > before we hit an addressing exception if it does not exist.
> > 
> > Signed-off-by: Cornelia Huck <cornelia.huck <at> de.ibm.com>
> > ---
> > drivers/s390/kvm/kvm_virtio.c | 21 +++++++++++++++++++++
> > 1 file changed, 21 insertions(+)
> > 
> > diff --git a/drivers/s390/kvm/kvm_virtio.c b/drivers/s390/kvm/kvm_virtio.c
> > index 47cccd5..408447c 100644
> > --- a/drivers/s390/kvm/kvm_virtio.c
> > +++ b/drivers/s390/kvm/kvm_virtio.c
> >  <at>  <at>  -418,6 +418,21  <at>  <at>  static void kvm_extint_handler(struct ext_code ext_code,
> > 	}
> > }
> > 
> > +static int __init test_devices_support(void)
> 
> Today we know what this function does, but the next person running into it has no clue. Maybe add a nice
description here that you're trying to access memory above ram? (is this even what you're doing here? my

(Continue reading)

headers

Cornelia Huck | 7 Aug 2012 16:52

[PATCH 2/4] s390: Add a mechanism to get the subchannel id.

This will be needed by the new virtio-ccw transport.

Signed-off-by: Cornelia Huck <cornelia.huck <at> de.ibm.com>
---
 arch/s390/include/asm/ccwdev.h |  5 +++++
 drivers/s390/cio/device_ops.c  | 10 ++++++++++
 2 files changed, 15 insertions(+)

diff --git a/arch/s390/include/asm/ccwdev.h b/arch/s390/include/asm/ccwdev.h
index 1cb4bb3..9ad79f7 100644
--- a/arch/s390/include/asm/ccwdev.h
+++ b/arch/s390/include/asm/ccwdev.h
 <at>  <at>  -18,6 +18,9  <at>  <at>  struct irb;
 struct ccw1;
 struct ccw_dev_id;

+/* from asm/schid.h */
+struct subchannel_id;
+
 /* simplified initializers for struct ccw_device:
  * CCW_DEVICE and CCW_DEVICE_DEVTYPE initialize one
  * entry in your MODULE_DEVICE_TABLE and set the match_flag correctly */
 <at>  <at>  -226,5 +229,7  <at>  <at>  int ccw_device_siosl(struct ccw_device *);
 // FIXME: these have to go
 extern int _ccw_device_get_subchannel_number(struct ccw_device *);

+extern void ccw_device_get_schid(struct ccw_device *, struct subchannel_id *);
+
 extern void *ccw_device_get_chp_desc(struct ccw_device *, int);
 #endif /* _S390_CCWDEV_H_ */

(Continue reading)

headers

Sebastian Ott | 13 Aug 2012 19:16

Re: [PATCH 2/4] s390: Add a mechanism to get the subchannel id.

On Tue, 7 Aug 2012, Cornelia Huck wrote:
> This will be needed by the new virtio-ccw transport.

We already have ccw_device_get_subchannel_id which is currently used by
qdio only and thus buried in an internal header file. So it would be
better to just clean up this one and make it available to virtio-ccw.
The function looks a little different to what you suggested by it should
do the trick.

---
 arch/s390/include/asm/ccwdev.h |    2 ++
 drivers/s390/cio/device.c      |   11 -----------
 drivers/s390/cio/device.h      |    2 --
 drivers/s390/cio/device_ops.c  |   13 +++++++++++++
 4 files changed, 15 insertions(+), 13 deletions(-)

--- a/arch/s390/include/asm/ccwdev.h
+++ b/arch/s390/include/asm/ccwdev.h
 <at>  <at>  -10,6 +10,7  <at>  <at> 

 #include <linux/device.h>
 #include <linux/mod_devicetable.h>
+#include <asm/schid.h>
 #include <asm/fcx.h>
 #include <asm/irq.h>

 <at>  <at>  -226,5 +227,6  <at>  <at>  int ccw_device_siosl(struct ccw_device *
 // FIXME: these have to go
 extern int _ccw_device_get_subchannel_number(struct ccw_device *);

(Continue reading)

headers

Sebastian Ott | 14 Aug 2012 10:52

Re: [PATCH 2/4] s390: Add a mechanism to get the subchannel id.

On Tue, 7 Aug 2012, Cornelia Huck wrote:
> +/**
> + * ccw_device_get_schid - obtain a subchannel id
> + *  <at> cdev: device to obtain the id for
> + *  <at> schid: where to fill in the values
> + */
> +void ccw_device_get_schid(struct ccw_device *cdev, struct subchannel_id *schid)
> +{
> +	*schid = cdev->private->schid;
> +}
> +EXPORT_SYMBOL(ccw_device_get_schid);

After I gave this some thought I like your version of this function
better. But please use the id of the parent subchannel instead of the
copy in cdev->private (since this will be removed soon). I'll do a
cleanup patch to convert the internal users of the old function to use
the one above.

Regards,
Sebastian

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Cornelia Huck | 14 Aug 2012 12:38

Re: [PATCH 2/4] s390: Add a mechanism to get the subchannel id.

On Tue, 14 Aug 2012 10:52:09 +0200 (CEST)
Sebastian Ott <sebott <at> linux.vnet.ibm.com> wrote:

> 
> On Tue, 7 Aug 2012, Cornelia Huck wrote:
> > +/**
> > + * ccw_device_get_schid - obtain a subchannel id
> > + *  <at> cdev: device to obtain the id for
> > + *  <at> schid: where to fill in the values
> > + */
> > +void ccw_device_get_schid(struct ccw_device *cdev, struct subchannel_id *schid)
> > +{
> > +	*schid = cdev->private->schid;
> > +}
> > +EXPORT_SYMBOL(ccw_device_get_schid);
> 
> After I gave this some thought I like your version of this function
> better. But please use the id of the parent subchannel instead of the
> copy in cdev->private (since this will be removed soon). I'll do a
> cleanup patch to convert the internal users of the old function to use
> the one above.

Good, will change that (I think we can rely on a ccw device always
having either a real subchannel or the orphanage pseudo subchannel as
parent).

Small taste question: EXPORT_SYMBOL vs EXPORT_SYMBOL_GPL?

headers

Sebastian Ott | 14 Aug 2012 12:53

Re: [PATCH 2/4] s390: Add a mechanism to get the subchannel id.


On Tue, 14 Aug 2012, Cornelia Huck wrote:
> Sebastian Ott <sebott <at> linux.vnet.ibm.com> wrote:
> > On Tue, 7 Aug 2012, Cornelia Huck wrote:
> > > +/**
> > > + * ccw_device_get_schid - obtain a subchannel id
> > > + *  <at> cdev: device to obtain the id for
> > > + *  <at> schid: where to fill in the values
> > > + */
> > > +void ccw_device_get_schid(struct ccw_device *cdev, struct subchannel_id *schid)
> > > +{
> > > +	*schid = cdev->private->schid;
> > > +}
> > > +EXPORT_SYMBOL(ccw_device_get_schid);
> > 
> > After I gave this some thought I like your version of this function
> > better. But please use the id of the parent subchannel instead of the
> > copy in cdev->private (since this will be removed soon). I'll do a
> > cleanup patch to convert the internal users of the old function to use
> > the one above.
> 
> Good, will change that (I think we can rely on a ccw device always
> having either a real subchannel or the orphanage pseudo subchannel as
> parent).

Yes you can rely on that.

> 
> Small taste question: EXPORT_SYMBOL vs EXPORT_SYMBOL_GPL?

(Continue reading)

headers

Cornelia Huck | 7 Aug 2012 16:52

[PATCH 4/4] s390/kvm: Split out early console code.

This code is transport agnostic and can be used by both the legacy
virtio code and virtio_ccw.

Signed-off-by: Cornelia Huck <cornelia.huck <at> de.ibm.com>
---
 drivers/s390/kvm/Makefile       |  2 +-
 drivers/s390/kvm/early_printk.c | 42 +++++++++++++++++++++++++++++++++++++++++
 drivers/s390/kvm/kvm_virtio.c   | 29 ++--------------------------
 drivers/s390/kvm/virtio_ccw.c   |  1 -
 4 files changed, 45 insertions(+), 29 deletions(-)
 create mode 100644 drivers/s390/kvm/early_printk.c

diff --git a/drivers/s390/kvm/Makefile b/drivers/s390/kvm/Makefile
index 241891a..a3c8fc4 100644
--- a/drivers/s390/kvm/Makefile
+++ b/drivers/s390/kvm/Makefile
 <at>  <at>  -6,4 +6,4  <at>  <at> 
 # it under the terms of the GNU General Public License (version 2 only)
 # as published by the Free Software Foundation.

-obj-$(CONFIG_S390_GUEST) += kvm_virtio.o virtio_ccw.o
+obj-$(CONFIG_S390_GUEST) += kvm_virtio.o early_printk.o virtio_ccw.o
diff --git a/drivers/s390/kvm/early_printk.c b/drivers/s390/kvm/early_printk.c
new file mode 100644
index 0000000..7831530
--- /dev/null
+++ b/drivers/s390/kvm/early_printk.c
 <at>  <at>  -0,0 +1,42  <at>  <at> 
+/*
+ * early_printk.c - code for early console output with virtio_console

(Continue reading)

headers

Cornelia Huck | 7 Aug 2012 16:52

[PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.

Add a driver for kvm guests that matches virtual ccw devices provided
by the host as virtio bridge devices.

These virtio-ccw devices use a special set of channel commands in order
to perform virtio functions.

Signed-off-by: Cornelia Huck <cornelia.huck <at> de.ibm.com>
---
 arch/s390/include/asm/irq.h   |   1 +
 arch/s390/kernel/irq.c        |   1 +
 drivers/s390/kvm/Makefile     |   2 +-
 drivers/s390/kvm/virtio_ccw.c | 761 ++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 764 insertions(+), 1 deletion(-)
 create mode 100644 drivers/s390/kvm/virtio_ccw.c

diff --git a/arch/s390/include/asm/irq.h b/arch/s390/include/asm/irq.h
index 2b9d418..b4bea53 100644
--- a/arch/s390/include/asm/irq.h
+++ b/arch/s390/include/asm/irq.h
 <at>  <at>  -31,6 +31,7  <at>  <at>  enum interruption_class {
 	IOINT_CTC,
 	IOINT_APB,
 	IOINT_CSC,
+	IOINT_VIR,
 	NMI_NMI,
 	NR_IRQS,
 };
diff --git a/arch/s390/kernel/irq.c b/arch/s390/kernel/irq.c
index dd7630d..2cc7eed 100644
--- a/arch/s390/kernel/irq.c

(Continue reading)

headers

Rusty Russell | 8 Aug 2012 06:22

Re: [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.

On Tue,  7 Aug 2012 16:52:47 +0200, Cornelia Huck <cornelia.huck <at> de.ibm.com> wrote:
> Add a driver for kvm guests that matches virtual ccw devices provided
> by the host as virtio bridge devices.

Hi Cornelia,

        OK, this is a good opportunity to fix some limitations, just as
we did for virtio_mmio (drivers/virtio/virtio_mmio.c).

1) Please don't limit yourself to 32 feature bits!  If you look at how
   virtio_mmio does it, they use a selector to index into a
   theoretically-infinite array of feature bits:

 * 0x010  R  HostFeatures     Features supported by the host
 * 0x014  W  HostFeaturesSel  Set of host features to access via HostFeatures
 *
 * 0x020  W  GuestFeatures    Features activated by the guest
 * 0x024  W  GuestFeaturesSel Set of activated features to set via GuestFeatures

2) Please also allow the guest to set the alignment for virtio ring
   layout (it controls the spacing between the rings), eg:

 * 0x03c  W  QueueAlign       Used Ring alignment for the current queue

3) Finally, make sure the guest can set the size of the queue, in case
   it can't allocate the size the host suggests, eg:

 * 0x034  R  QueueNumMax      Maximum size of the currently selected queue
 * 0x038  W  QueueNum         Queue size for the currently selected queue

(Continue reading)

headers

Cornelia Huck | 13 Aug 2012 10:56

Re: [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.

On Wed, 08 Aug 2012 13:52:57 +0930
Rusty Russell <rusty <at> rustcorp.com.au> wrote:

> On Tue,  7 Aug 2012 16:52:47 +0200, Cornelia Huck <cornelia.huck <at> de.ibm.com> wrote:
> > Add a driver for kvm guests that matches virtual ccw devices provided
> > by the host as virtio bridge devices.
> 
> Hi Cornelia,
> 
>         OK, this is a good opportunity to fix some limitations, just as
> we did for virtio_mmio (drivers/virtio/virtio_mmio.c).
> 
> 1) Please don't limit yourself to 32 feature bits!  If you look at how
>    virtio_mmio does it, they use a selector to index into a
>    theoretically-infinite array of feature bits:
> 
>  * 0x010  R  HostFeatures     Features supported by the host
>  * 0x014  W  HostFeaturesSel  Set of host features to access via HostFeatures
>  *
>  * 0x020  W  GuestFeatures    Features activated by the guest
>  * 0x024  W  GuestFeaturesSel Set of activated features to set via GuestFeatures

It should be easy to extend the data processed by the feature ccws to a
feature/index combination. Would it be practical to limit the index to
an 8 bit value?

> 
> 2) Please also allow the guest to set the alignment for virtio ring
>    layout (it controls the spacing between the rings), eg:
>

(Continue reading)

headers

Rusty Russell | 14 Aug 2012 02:10

Re: [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.

On Mon, 13 Aug 2012 10:56:38 +0200, Cornelia Huck <cornelia.huck <at> de.ibm.com> wrote:
> On Wed, 08 Aug 2012 13:52:57 +0930
> Rusty Russell <rusty <at> rustcorp.com.au> wrote:
> 
> > On Tue,  7 Aug 2012 16:52:47 +0200, Cornelia Huck <cornelia.huck <at> de.ibm.com> wrote:
> > 1) Please don't limit yourself to 32 feature bits!  If you look at how
> >    virtio_mmio does it, they use a selector to index into a
> >    theoretically-infinite array of feature bits:
> 
> It should be easy to extend the data processed by the feature ccws to a
> feature/index combination. Would it be practical to limit the index to
> an 8 bit value?

256 feature bits?  That seems like it could one day be limiting.  Or an
8 bit accessor into feature words?  8192 seems enough for anyone sane.

> > Note that we're also speculating a move to a new vring format, which
> > will probably be little-endian.  But you probably want a completely new
> > ccw code for that anyway.
> 
> Do you have a pointer to that discussion handy?
> 
> If the host may support different vring formats, I'll probably want to
> add some kind of discovery mechanism for that as well (what discovery
> mechanism depends on whether this would be per-device or per-machine).

It would be per-machine; per-device would be a bit crazy.  We'd
deprecate the old ring format.

There's been no consistent thread on the ideas for a ring change,

(Continue reading)

headers

Cornelia Huck | 14 Aug 2012 13:03

Re: [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.

On Tue, 14 Aug 2012 09:40:01 +0930
Rusty Russell <rusty <at> rustcorp.com.au> wrote:

> On Mon, 13 Aug 2012 10:56:38 +0200, Cornelia Huck <cornelia.huck <at> de.ibm.com> wrote:
> > On Wed, 08 Aug 2012 13:52:57 +0930
> > Rusty Russell <rusty <at> rustcorp.com.au> wrote:
> > 
> > > On Tue,  7 Aug 2012 16:52:47 +0200, Cornelia Huck <cornelia.huck <at> de.ibm.com> wrote:
> > > 1) Please don't limit yourself to 32 feature bits!  If you look at how
> > >    virtio_mmio does it, they use a selector to index into a
> > >    theoretically-infinite array of feature bits:
> > 
> > It should be easy to extend the data processed by the feature ccws to a
> > feature/index combination. Would it be practical to limit the index to
> > an 8 bit value?
> 
> 256 feature bits?  That seems like it could one day be limiting.  Or an
> 8 bit accessor into feature words?  8192 seems enough for anyone sane.

An 8 bit accessor. I hope everybody stays on the sane side :)

> 
> > > Note that we're also speculating a move to a new vring format, which
> > > will probably be little-endian.  But you probably want a completely new
> > > ccw code for that anyway.
> > 
> > Do you have a pointer to that discussion handy?
> > 
> > If the host may support different vring formats, I'll probably want to
> > add some kind of discovery mechanism for that as well (what discovery

(Continue reading)

headers

Rusty Russell | 15 Aug 2012 05:15

Re: [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.

On Tue, 14 Aug 2012 13:03:34 +0200, Cornelia Huck <cornelia.huck <at> de.ibm.com> wrote:
> > It would be per-machine; per-device would be a bit crazy.  We'd
> > deprecate the old ring format.
> > 
> > There's been no consistent thread on the ideas for a ring change,
> > unfortunately, but you can find interesting parts here, off this thread:
> > 
> > Message-ID: <8762gj6q5r.fsf <at> rustcorp.com.au>
> > Subject: Re: [RFC 7/11] virtio_pci: new, capability-aware driver.
> 
> I've read a bit through this and it looks like this is really virtio-2
> or so. How about discoverability by the guest? Guests will likely have
> to support both formats, and forcing them to look at the feature bits
> for each device in order to figure out the queue format feels wrong if
> it is going to be the same format for the whole machine anyway.

Yes, it needs some out-of-band acknowledgement mechanism by the guest.
Might be worth putting a max version number somewhere, which the guest
writes to acknowledge (ie. currently it would be 1, and the guest would
always write a 1).

Cheers,
Rusty.

headers

Anthony Liguori | 14 Aug 2012 21:56

Re: [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.

Cornelia Huck <cornelia.huck <at> de.ibm.com> writes:

> Add a driver for kvm guests that matches virtual ccw devices provided
> by the host as virtio bridge devices.
>
> These virtio-ccw devices use a special set of channel commands in order
> to perform virtio functions.
>
> Signed-off-by: Cornelia Huck <cornelia.huck <at> de.ibm.com>

Hi,

Have you written an appendix for the virtio specification for
virtio-ccw?  I think it would be good to include in this series for the
purposes of review.

Regards,

Anthony Liguori

> ---
>  arch/s390/include/asm/irq.h   |   1 +
>  arch/s390/kernel/irq.c        |   1 +
>  drivers/s390/kvm/Makefile     |   2 +-
>  drivers/s390/kvm/virtio_ccw.c | 761 ++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 764 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/s390/kvm/virtio_ccw.c
>
> diff --git a/arch/s390/include/asm/irq.h b/arch/s390/include/asm/irq.h
> index 2b9d418..b4bea53 100644

(Continue reading)

headers

Rusty Russell | 15 Aug 2012 09:28

Re: [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.

On Tue, 14 Aug 2012 14:56:07 -0500, Anthony Liguori <aliguori <at> us.ibm.com> wrote:
> Cornelia Huck <cornelia.huck <at> de.ibm.com> writes:
> 
> > Add a driver for kvm guests that matches virtual ccw devices provided
> > by the host as virtio bridge devices.
> >
> > These virtio-ccw devices use a special set of channel commands in order
> > to perform virtio functions.
> >
> > Signed-off-by: Cornelia Huck <cornelia.huck <at> de.ibm.com>
> 
> Hi,
> 
> Have you written an appendix for the virtio specification for
> virtio-ccw?  I think it would be good to include in this series for the
> purposes of review.

Might be nice, but don't get fancy about it.  Text will be fine and I
can cut & paste it in once it's finalized.

Cheers,
Rusty.

headers

Christian Borntraeger | 15 Aug 2012 09:48

Re: [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.

>> Have you written an appendix for the virtio specification for
>> virtio-ccw?  I think it would be good to include in this series for the
>> purposes of review.
> 
> Might be nice, but don't get fancy about it.  Text will be fine and I
> can cut & paste it in once it's finalized.

There was a patch against the virtio spec in the patch series. Did it not
make it to you?

But Anthony is right, the spec is important, because the two main things 
that we need to get right are the 2 interfaces
guest<->host and userspace(qemu)<->kvm.
Everything else is not an ABI and can be fixed later on if necessary. 

Regarding the guest<->host interface a lot of things are mandated by the 
channel-IO architecture. We have also reserved some IDs for virtio 
(control unit type 0x3832, channel path type 0x32 and channel subsystem id 0xfe)
so we just have to focus on the virtio part (thanks Rusty for the good feedback
already).

Regarding the qemu<->kvm interface it is important to have an interface that
- allows us to be architectural compliant
- which is fast
- which must not prevent features like vhost
- which allows to implement live migration
- ...?

Christian

(Continue reading)

headers

Rusty Russell | 21 Aug 2012 07:35

Re: [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.

On Wed, 15 Aug 2012 09:48:44 +0200, Christian Borntraeger <borntraeger <at> de.ibm.com> wrote:
> >> Have you written an appendix for the virtio specification for
> >> virtio-ccw?  I think it would be good to include in this series for the
> >> purposes of review.
> > 
> > Might be nice, but don't get fancy about it.  Text will be fine and I
> > can cut & paste it in once it's finalized.
> 
> There was a patch against the virtio spec in the patch series. Did it not
> make it to you?

Yes, I got it, thanks (not in this thread, but that's OK).  Will hold
off until finalized.

Cheers,
Rusty.