qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: linux-s390 <linux-s390@vger.kernel.org>,
	Anthony Liguori <aliguori@us.ibm.com>, KVM <kvm@vger.kernel.org>,
	Gleb Natapov <gleb@redhat.com>, Carsten Otte <cotte@de.ibm.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [Qemu-devel] [PATCH 8/8] s390: Add new channel I/O based virtio transport.
Date: Tue, 11 Dec 2012 14:03:58 +0100	[thread overview]
Message-ID: <20121211140358.1b39b8c6@BR9GNB5Z> (raw)
In-Reply-To: <DC47DBAD-3386-4443-BBE4-48BD0BDACEE6@suse.de>

On Tue, 11 Dec 2012 11:53:18 +0100
Alexander Graf <agraf@suse.de> wrote:

> 
> On 07.12.2012, at 13:50, Cornelia Huck wrote:
> 
> > Add a new virtio transport that uses channel commands to perform
> > virtio operations.
> > 
> > Add a new machine type s390-ccw that uses this virtio-ccw transport
> > and make it the default machine for s390.
> > 
> > Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> > ---
> > hw/s390-virtio.c       | 149 ++++++--
> > hw/s390x/Makefile.objs |   1 +
> > hw/s390x/virtio-ccw.c  | 909 +++++++++++++++++++++++++++++++++++++++++++++++++
> > hw/s390x/virtio-ccw.h  |  81 +++++
> > trace-events           |   4 +
> > 5 files changed, 1124 insertions(+), 20 deletions(-)
> > create mode 100644 hw/s390x/virtio-ccw.c
> > create mode 100644 hw/s390x/virtio-ccw.h
> > 
> > diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
> > index 9e1afb2..f29ff74 100644
> > --- a/hw/s390-virtio.c
> > +++ b/hw/s390-virtio.c
> > @@ -33,6 +33,8 @@
> > 
> > #include "hw/s390-virtio-bus.h"
> > #include "hw/s390x/sclp.h"
> > +#include "hw/s390x/css.h"
> > +#include "hw/s390x/virtio-ccw.h"
> > 
> > //#define DEBUG_S390
> > 
> > @@ -47,6 +49,7 @@
> > #define KVM_S390_VIRTIO_NOTIFY          0
> > #define KVM_S390_VIRTIO_RESET           1
> > #define KVM_S390_VIRTIO_SET_STATUS      2
> > +#define KVM_S390_VIRTIO_CCW_NOTIFY      3
> > 
> > #define KERN_IMAGE_START                0x010000UL
> > #define KERN_PARM_AREA                  0x010480UL
> > @@ -63,6 +66,7 @@
> > 
> > static VirtIOS390Bus *s390_bus;
> > static S390CPU **ipi_states;
> > +VirtioCcwBus *ccw_bus;
> > 
> > S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
> > {
> > @@ -76,15 +80,21 @@ S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
> > int s390_virtio_hypercall(CPUS390XState *env, uint64_t mem, uint64_t hypercall)
> > {
> >     int r = 0, i;
> > +    int cssid, ssid, schid, m;
> > +    SubchDev *sch;
> > 
> >     dprintf("KVM hypercall: %ld\n", hypercall);
> >     switch (hypercall) {
> >     case KVM_S390_VIRTIO_NOTIFY:
> >         if (mem > ram_size) {
> > -            VirtIOS390Device *dev = s390_virtio_bus_find_vring(s390_bus,
> > -                                                               mem, &i);
> > -            if (dev) {
> > -                virtio_queue_notify(dev->vdev, i);
> > +            if (s390_bus) {
> > +                VirtIOS390Device *dev = s390_virtio_bus_find_vring(s390_bus,
> > +                                                                   mem, &i);
> > +                if (dev) {
> > +                    virtio_queue_notify(dev->vdev, i);
> > +                } else {
> > +                    r = -EINVAL;
> > +                }
> 
> We really want to factor out the DIAG handling code similar to how spapr handles its hypercalls. That way the legacy s390-virtio machine can register a VIRTIO_NOTIFY hypercall that works for it here, while the s390-virtio-ccw machine doesn't.
> 
> >             } else {
> >                 r = -EINVAL;
> >             }
> > @@ -93,28 +103,49 @@ int s390_virtio_hypercall(CPUS390XState *env, uint64_t mem, uint64_t hypercall)
> >         }
> >         break;
> >     case KVM_S390_VIRTIO_RESET:
> > -    {
> > -        VirtIOS390Device *dev;
> > -
> > -        dev = s390_virtio_bus_find_mem(s390_bus, mem);
> > -        virtio_reset(dev->vdev);
> > -        stb_phys(dev->dev_offs + VIRTIO_DEV_OFFS_STATUS, 0);
> > -        s390_virtio_device_sync(dev);
> > -        s390_virtio_reset_idx(dev);
> > +        if (s390_bus) {
> > +            VirtIOS390Device *dev;
> > +
> > +            dev = s390_virtio_bus_find_mem(s390_bus, mem);
> > +            virtio_reset(dev->vdev);
> > +            stb_phys(dev->dev_offs + VIRTIO_DEV_OFFS_STATUS, 0);
> > +            s390_virtio_device_sync(dev);
> > +            s390_virtio_reset_idx(dev);
> > +        } else {
> > +            r = -EINVAL;
> > +        }
> >         break;
> > -    }
> >     case KVM_S390_VIRTIO_SET_STATUS:
> > -    {
> > -        VirtIOS390Device *dev;
> > +        if (s390_bus) {
> > +            VirtIOS390Device *dev;
> > 
> > -        dev = s390_virtio_bus_find_mem(s390_bus, mem);
> > -        if (dev) {
> > -            s390_virtio_device_update_status(dev);
> > +            dev = s390_virtio_bus_find_mem(s390_bus, mem);
> > +            if (dev) {
> > +                s390_virtio_device_update_status(dev);
> > +            } else {
> > +                r = -EINVAL;
> > +            }
> >         } else {
> >             r = -EINVAL;
> >         }
> >         break;
> > -    }
> > +    case KVM_S390_VIRTIO_CCW_NOTIFY:
> > +        if (ccw_bus) {
> > +            if (ioinst_disassemble_sch_ident(env->regs[2], &m, &cssid, &ssid,
> > +                                             &schid)) {
> > +                r = -EINVAL;
> > +            } else {
> > +                sch = css_find_subch(m, cssid, ssid, schid);
> > +                if (sch && css_subch_visible(sch)) {
> > +                    virtio_queue_notify(virtio_ccw_get_vdev(sch), env->regs[3]);
> > +                } else {
> > +                    r = -EINVAL;
> > +                }
> > +            }
> > +         } else {
> > +             r = -EINVAL;
> > +         }
> > +         break;
> >     default:
> >         r = -EINVAL;
> >         break;
> > @@ -370,7 +401,6 @@ static QEMUMachine s390_machine = {
> >     .no_sdcard = 1,
> >     .use_virtcon = 1,
> >     .max_cpus = 255,
> > -    .is_default = 1,
> > };
> > 
> > static void s390_machine_init(void)
> > @@ -379,3 +409,82 @@ static void s390_machine_init(void)
> > }
> > 
> > machine_init(s390_machine_init);
> > +
> > +static void ccw_init(QEMUMachineInitArgs *args)
> 
> Do you think it'd be possible to move this into its own .c file?

Any particular reason why it should be moved? I saw this file as
'handle generic s390 virtio stuff'.

> 
> > +{
> > +    ram_addr_t my_ram_size = args->ram_size;
> > +    ram_addr_t ram_size = args->ram_size;
> > +    const char *cpu_model = args->cpu_model;
> > +    const char *kernel_filename = args->kernel_filename;
> > +    const char *kernel_cmdline = args->kernel_cmdline;
> > +    const char *initrd_filename = args->initrd_filename;
> > +    CPUS390XState *env = NULL;
> > +    MemoryRegion *sysmem = get_system_memory();
> > +    MemoryRegion *ram = g_new(MemoryRegion, 1);
> > +    int shift = 0;
> > +    uint8_t *storage_keys;
> > +    int ret;
> > +
> > +    /* s390x ram size detection needs a 16bit multiplier + an increment. So
> > +       guests > 64GB can be specified in 2MB steps etc. */
> > +    while ((my_ram_size >> (20 + shift)) > 65535) {
> > +        shift++;
> > +    }
> > +    my_ram_size = my_ram_size >> (20 + shift) << (20 + shift);
> > +
> > +    /* lets propagate the changed ram size into the global variable. */
> > +    ram_size = my_ram_size;
> > +
> > +    /* get a BUS */
> > +    ccw_bus = virtio_ccw_bus_init();
> > +    s390_sclp_init();
> > +
> > +    /* allocate RAM */
> > +    memory_region_init_ram(ram, "s390.ram", my_ram_size);
> > +    vmstate_register_ram_global(ram);
> > +    memory_region_add_subregion(sysmem, 0, ram);
> > +
> > +    /* allocate storage keys */
> > +    storage_keys = g_malloc0(my_ram_size / TARGET_PAGE_SIZE);
> > +
> > +    /* init CPUs */
> > +    env = s390_init_cpus(cpu_model, storage_keys);
> > +
> > +    kvm_s390_enable_css_support(env);
> > +
> > +    /*
> > +     * Create virtual css and set it as default so that non mcss-e
> > +     * enabled guests only see virtio devices.
> > +     */
> > +    ret = css_create_css_image(VIRTUAL_CSSID, true);
> > +    assert(ret == 0);
> > +
> > +
> > +    s390_set_up_kernel(env, kernel_filename, kernel_cmdline, initrd_filename);
> > +
> > +    /* Create VirtIO network adapters */
> > +    s390_create_virtio_net((BusState *)ccw_bus, "virtio-net-ccw");
> > +
> > +}
> > +
> > +static QEMUMachine ccw_machine = {
> > +    .name = "s390-ccw-virtio",
> > +    .alias = "s390-ccw",
> > +    .desc = "VirtIO-ccw based S390 machine",
> > +    .init = ccw_init,
> > +    .no_cdrom = 1,
> > +    .no_floppy = 1,
> > +    .no_serial = 1,
> > +    .no_parallel = 1,
> > +    .no_sdcard = 1,
> > +    .use_virtcon = 1,
> > +    .max_cpus = 255,
> > +    .is_default = 1,
> > +};
> > +
> > +static void ccw_machine_init(void)
> > +{
> > +    qemu_register_machine(&ccw_machine);
> > +}
> > +
> > +machine_init(ccw_machine_init);
> > diff --git a/hw/s390x/Makefile.objs b/hw/s390x/Makefile.objs
> > index 378b099..d408558 100644
> > --- a/hw/s390x/Makefile.objs
> > +++ b/hw/s390x/Makefile.objs
> > @@ -5,3 +5,4 @@ obj-y += sclp.o
> > obj-y += event-facility.o
> > obj-y += sclpquiesce.o sclpconsole.o
> > obj-y += css.o
> > +obj-y += virtio-ccw.o
> > diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> > new file mode 100644
> > index 0000000..b4624ab
> > --- /dev/null
> > +++ b/hw/s390x/virtio-ccw.c
> > @@ -0,0 +1,909 @@
> > +/*
> > + * virtio ccw target implementation
> 
> Please extract this into a separate patch.

You mean first add the virtio-ccw backend and then introduce the new
machine?


> > +static int virtio_ccw_device_init(VirtioCcwData *dev, VirtIODevice *vdev)
> > +{
> > +    unsigned int cssid = 0;
> > +    unsigned int ssid = 0;
> > +    unsigned int schid;
> > +    unsigned int devno;
> > +    bool have_devno = false;
> > +    bool found = false;
> > +    SubchDev *sch;
> > +    int ret;
> > +    int num;
> > +
> > +    sch = g_malloc0(sizeof(SubchDev));
> 
> Any reason to not just make sch part of dev?

If anything, we'd probably want the virtio-ccw stuff extending the
generic subchannel stuff (so that we can have a basic subchannel
structure which might later be extended in a different way if we want
real device passthrough).

I'll try to implement it in such a way that it can be easily refactored
and extended.

  parent reply	other threads:[~2012-12-11 13:04 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-07 12:50 [Qemu-devel] [RFC PATCH v4 0/8] s390: channel I/O support in qemu Cornelia Huck
2012-12-07 12:50 ` [Qemu-devel] [PATCH 1/8] Update linux headers Cornelia Huck
2012-12-07 13:01   ` Peter Maydell
2012-12-07 14:08     ` Cornelia Huck
2012-12-07 12:50 ` [Qemu-devel] [PATCH 2/8] s390: Channel I/O basic defintions Cornelia Huck
2012-12-10  8:07   ` Alexander Graf
2012-12-10 10:18     ` Cornelia Huck
2012-12-11 10:27       ` Alexander Graf
2012-12-11 12:48         ` Cornelia Huck
2012-12-07 12:50 ` [Qemu-devel] [PATCH 3/8] s390: I/O interrupt and machine check injection Cornelia Huck
2012-12-10  8:20   ` Alexander Graf
2012-12-10 10:27     ` Cornelia Huck
2012-12-11  0:26       ` Rob Landley
2012-12-11 12:17         ` Cornelia Huck
2012-12-11 10:29       ` Alexander Graf
2012-12-11 12:50         ` Cornelia Huck
2012-12-07 12:50 ` [Qemu-devel] [PATCH 4/8] s390: Add channel I/O instructions Cornelia Huck
2012-12-10  9:00   ` Alexander Graf
2012-12-10  9:18     ` Cornelia Huck
2012-12-11 10:18       ` Alexander Graf
2012-12-11 12:53         ` Cornelia Huck
2012-12-07 12:50 ` [Qemu-devel] [PATCH 5/8] s390: Virtual channel subsystem support Cornelia Huck
2012-12-07 12:50 ` [Qemu-devel] [PATCH 6/8] s390: Wire up channel I/O in kvm Cornelia Huck
2012-12-10  9:40   ` Alexander Graf
2012-12-10 10:29     ` Cornelia Huck
2012-12-07 12:50 ` [Qemu-devel] [PATCH 7/8] s390-virtio: Factor out some initialization code Cornelia Huck
2012-12-07 12:50 ` [Qemu-devel] [PATCH 8/8] s390: Add new channel I/O based virtio transport Cornelia Huck
2012-12-11 10:53   ` Alexander Graf
2012-12-11 12:06     ` Christian Borntraeger
2012-12-12  0:38       ` Alexander Graf
2012-12-11 13:03     ` Cornelia Huck [this message]
2012-12-12  0:39       ` Alexander Graf
2013-01-16 13:24   ` Alexander Graf
2013-01-16 13:53     ` Alexander Graf
2013-01-16 13:58       ` Cornelia Huck
2013-01-16 16:46     ` Richard Henderson
2013-01-16 17:05       ` Alexander Graf
2012-12-10  8:02 ` [Qemu-devel] [RFC PATCH v4 0/8] s390: channel I/O support in qemu Alexander Graf
2012-12-10 10:34   ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121211140358.1b39b8c6@BR9GNB5Z \
    --to=cornelia.huck@de.ibm.com \
    --cc=agraf@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cotte@de.ibm.com \
    --cc=gleb@redhat.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=sebott@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).