Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5645595ybe; Tue, 10 Sep 2019 06:54:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqwfKw/LyKYd8KCgzPeypsgVdhcnnvjUiJnOpdb9C422Ef+derM8BxiZZu0DkIJUeObr66/+ X-Received: by 2002:aa7:dacc:: with SMTP id x12mr24322889eds.116.1568123683108; Tue, 10 Sep 2019 06:54:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568123683; cv=none; d=google.com; s=arc-20160816; b=kuEGqMWltmymUG3M9dNmW0+WHnkNPq9TbicZE84nWqum6HzHvYINNZrvs/K04hnGwA 4RO53hhbpX/ZbFrqgC1zZeCdENK2u5o8OnH4eji2Obz2CMm3b1NV/HP4CHp1VWIzdrMy nVZHrUtpQy5mQckjAwD9ia8WfvB9XjHcDZzm0MFpICmWHIc+8p5/uHsJC+L9fpxV/Bhg SIo6LydWCfjLTcP6P13UmAfL+2J8dVeXCqYogIux1xyJoqkpNrw1wDBrOk9vqphCG748 bfcNTKtySvGHEgHEPtBSo8nvDqetpKBnmOgUbW7P7rdRPPXugwViE3xGvjmJG7U7Wkyd X7lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=ul70AkksitVVi2/lSKzC6ijk0O+ui69VWHD+F0xUvfQ=; b=Pwusr/yBnwg0Mi8yW8eAlz6plruh5AIONB2vE+CMRL/jPhkaMlLJSRoYfhKsrObSst n5UXa5fscHoc9HWG8e9Ib65UkEoaj53B0o5kCKFKDkshc1BKO6+agwD4kl16YwcD+RET qYikY9sDCH3OLAQWaeXr5wBbmxrDLZiWAJ7ozyXfVnHdZa/lzH6CsbRpvRdjs1FOWNki xyrBvIYMvXpcIttFgWOrUarqHOTfkS/iPe19nzbP3yAku/2A/1DWfoY4PreQfQE5jMzo JCPk/xRSFkKLYk5YENYEmKgg931iioeflt1ZMEyTJAmy8og7w/vDWcdxkZjybyC+boPY LAJg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e48si11212168edd.239.2019.09.10.06.54.18; Tue, 10 Sep 2019 06:54:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730674AbfIJNNR (ORCPT + 99 others); Tue, 10 Sep 2019 09:13:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33240 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726175AbfIJNNR (ORCPT ); Tue, 10 Sep 2019 09:13:17 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7B5FB300DA3A; Tue, 10 Sep 2019 13:13:16 +0000 (UTC) Received: from [10.72.12.23] (ovpn-12-23.pek2.redhat.com [10.72.12.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id B145A6012A; Tue, 10 Sep 2019 13:13:01 +0000 (UTC) Subject: Re: [RFC PATCH 3/4] virtio: introudce a mdev based transport To: "Michael S. Tsirkin" Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kwankhede@nvidia.com, alex.williamson@redhat.com, cohuck@redhat.com, tiwei.bie@intel.com, maxime.coquelin@redhat.com, cunming.liang@intel.com, zhihong.wang@intel.com, rob.miller@broadcom.com, idos@mellanox.com, xiao.w.wang@intel.com, haotian.wang@sifive.com References: <20190910081935.30516-1-jasowang@redhat.com> <20190910081935.30516-4-jasowang@redhat.com> <20190910055744-mutt-send-email-mst@kernel.org> From: Jason Wang Message-ID: <572ffc34-3081-8503-d3cc-192edc9b5311@redhat.com> Date: Tue, 10 Sep 2019 21:13:02 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190910055744-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Tue, 10 Sep 2019 13:13:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/9/10 下午6:01, Michael S. Tsirkin wrote: >> +#ifndef _LINUX_VIRTIO_MDEV_H >> +#define _LINUX_VIRTIO_MDEV_H >> + >> +#include >> +#include >> +#include >> + >> +/* >> + * Ioctls >> + */ > Pls add a bit more content here. It's redundant to state these > are ioctls. Much better to document what does each one do. Ok. > >> + >> +struct virtio_mdev_callback { >> + irqreturn_t (*callback)(void *); >> + void *private; >> +}; >> + >> +#define VIRTIO_MDEV 0xAF >> +#define VIRTIO_MDEV_SET_VQ_CALLBACK _IOW(VIRTIO_MDEV, 0x00, \ >> + struct virtio_mdev_callback) >> +#define VIRTIO_MDEV_SET_CONFIG_CALLBACK _IOW(VIRTIO_MDEV, 0x01, \ >> + struct virtio_mdev_callback) > Function pointer in an ioctl parameter? How does this ever make sense? I admit this is hacky (casting). > And can't we use a couple of registers for this, and avoid ioctls? Yes, how about something like interrupt numbers for each virtqueue and config? > >> + >> +#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev" >> + >> +/* >> + * Control registers >> + */ >> + >> +/* Magic value ("virt" string) - Read Only */ >> +#define VIRTIO_MDEV_MAGIC_VALUE 0x000 >> + >> +/* Virtio device version - Read Only */ >> +#define VIRTIO_MDEV_VERSION 0x004 >> + >> +/* Virtio device ID - Read Only */ >> +#define VIRTIO_MDEV_DEVICE_ID 0x008 >> + >> +/* Virtio vendor ID - Read Only */ >> +#define VIRTIO_MDEV_VENDOR_ID 0x00c >> + >> +/* Bitmask of the features supported by the device (host) >> + * (32 bits per set) - Read Only */ >> +#define VIRTIO_MDEV_DEVICE_FEATURES 0x010 >> + >> +/* Device (host) features set selector - Write Only */ >> +#define VIRTIO_MDEV_DEVICE_FEATURES_SEL 0x014 >> + >> +/* Bitmask of features activated by the driver (guest) >> + * (32 bits per set) - Write Only */ >> +#define VIRTIO_MDEV_DRIVER_FEATURES 0x020 >> + >> +/* Activated features set selector - Write Only */ >> +#define VIRTIO_MDEV_DRIVER_FEATURES_SEL 0x024 >> + >> +/* Queue selector - Write Only */ >> +#define VIRTIO_MDEV_QUEUE_SEL 0x030 >> + >> +/* Maximum size of the currently selected queue - Read Only */ >> +#define VIRTIO_MDEV_QUEUE_NUM_MAX 0x034 >> + >> +/* Queue size for the currently selected queue - Write Only */ >> +#define VIRTIO_MDEV_QUEUE_NUM 0x038 >> + >> +/* Ready bit for the currently selected queue - Read Write */ >> +#define VIRTIO_MDEV_QUEUE_READY 0x044 > Is this same as started? Do you mean "status"? > >> + >> +/* Alignment of virtqueue - Read Only */ >> +#define VIRTIO_MDEV_QUEUE_ALIGN 0x048 >> + >> +/* Queue notifier - Write Only */ >> +#define VIRTIO_MDEV_QUEUE_NOTIFY 0x050 >> + >> +/* Device status register - Read Write */ >> +#define VIRTIO_MDEV_STATUS 0x060 >> + >> +/* Selected queue's Descriptor Table address, 64 bits in two halves */ >> +#define VIRTIO_MDEV_QUEUE_DESC_LOW 0x080 >> +#define VIRTIO_MDEV_QUEUE_DESC_HIGH 0x084 >> + >> +/* Selected queue's Available Ring address, 64 bits in two halves */ >> +#define VIRTIO_MDEV_QUEUE_AVAIL_LOW 0x090 >> +#define VIRTIO_MDEV_QUEUE_AVAIL_HIGH 0x094 >> + >> +/* Selected queue's Used Ring address, 64 bits in two halves */ >> +#define VIRTIO_MDEV_QUEUE_USED_LOW 0x0a0 >> +#define VIRTIO_MDEV_QUEUE_USED_HIGH 0x0a4 >> + >> +/* Configuration atomicity value */ >> +#define VIRTIO_MDEV_CONFIG_GENERATION 0x0fc >> + >> +/* The config space is defined by each driver as >> + * the per-driver configuration space - Read Write */ >> +#define VIRTIO_MDEV_CONFIG 0x100 > Mixing device and generic config space is what virtio pci did, > caused lots of problems with extensions. > It would be better to reserve much more space. I see, will do this. Thanks > > >> + >> +#endif >> + >> + >> +/* Ready bit for the currently selected queue - Read Write */ >> -- >> 2.19.1