Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp10762781ybl; Fri, 27 Dec 2019 01:40:11 -0800 (PST) X-Google-Smtp-Source: APXvYqwtU3Z5cGwUoyjJzPMY0ZXwKhjIFP0eEsW3+KEw5c5IgHkcOgcrM5VDdAgxRMNrPXceAvdp X-Received: by 2002:a9d:7ad9:: with SMTP id m25mr52640123otn.13.1577439611696; Fri, 27 Dec 2019 01:40:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577439611; cv=none; d=google.com; s=arc-20160816; b=tvbGMMR0htVC/eTuv3rprloeFCOB0/3LXHuy3Dc4FWz2sXVVnty5OxJM5iZROnIkJu RwRYc8CEt+lBGB+sJ9uqanfQYUsb1j59EW/2EhUnzyIGXxc00i9bSBH1d3/HnrDYbLb+ qRwXr+x32TEtNLWBnGnNLFrMth9gdE12E+cVJKbnSU4g8HFoIAcyxSCWphLvbOeL9Z9d oE80RHcIcaH3oL0AoQVfhY2jHBYi8Y6xek7iE9kd6KRDJuEGGLll4VPCHk78gKwiuOru yKjgxYdDrHCmZtZND6kVEdSmMF1g1qvINaOr4inqcRlFM41VWft2UP/aVMkak2opiKud SLlQ== 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:references:cc:to:subject:from; bh=IvRKE3aEit+B1YAsqZzjyp/91K6B43sEC89eOk4gol0=; b=LFjWtsJeyNvjMpJnxURZcqdhFGIDNUYVk+ZMq4l5tm7h0Us8montp0OCLKCXlnpf6v 2aavoTF2S9maEovYr82SSA0g8SuTD4eScD7F9Cn5PBp7SBQFKaQInRfecJmE93CoLbiF 99vO5PH9w0xPZyIJIZb6nBNooA6zCifFs18LqXI3OG7E1bcYfII9ZOUAjJVAzrKiGjQb nX9rPfNpVvwIWEc2nZNBviFFCBDxQo4t/D2e3cUvWPAwdtXEOnMKd4JMimQBDio37oL5 Yp1/uP1dvfXxxWplFcfU+NZcoCtgy8hbV9eJ6xzCu84gQyp9i4W0PJZw/3D7QqeXaVh4 E6eQ== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h139si15705254oib.85.2019.12.27.01.40.00; Fri, 27 Dec 2019 01:40:11 -0800 (PST) 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726579AbfL0Jh0 (ORCPT + 99 others); Fri, 27 Dec 2019 04:37:26 -0500 Received: from mga04.intel.com ([192.55.52.120]:6989 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725904AbfL0JhZ (ORCPT ); Fri, 27 Dec 2019 04:37:25 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Dec 2019 01:37:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,362,1571727600"; d="scan'208";a="220469731" Received: from liujing-mobl1.ccr.corp.intel.com (HELO [10.238.130.143]) ([10.238.130.143]) by orsmga003.jf.intel.com with ESMTP; 27 Dec 2019 01:37:23 -0800 From: "Liu, Jing2" Subject: Re: [virtio-dev] Re: [PATCH v1 2/2] virtio-mmio: add features for virtio-mmio specification version 3 To: Jason Wang , Zha Bin , linux-kernel@vger.kernel.org Cc: mst@redhat.com, slp@redhat.com, virtio-dev@lists.oasis-open.org, gerry@linux.alibaba.com, jing2.liu@intel.com, chao.p.peng@intel.com References: <85eeab19-1f53-6c45-95a2-44c1cfd39184@redhat.com> Message-ID: <28da67db-73ab-f772-fb00-5a471b746fc5@linux.intel.com> Date: Fri, 27 Dec 2019 17:37:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <85eeab19-1f53-6c45-95a2-44c1cfd39184@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jason, Thanks for reviewing the patches!  [...] >> - >> +#include >> +#include >>     /* The alignment to use between consumer and producer parts of >> vring. >>    * Currently hardcoded to the page size. */ >> @@ -90,6 +90,12 @@ struct virtio_mmio_device { >>       /* a list of queues so we can dispatch IRQs */ >>       spinlock_t lock; >>       struct list_head virtqueues; >> + >> +    int doorbell_base; >> +    int doorbell_scale; > > > It's better to use the terminology defined by spec, e.g > notify_base/notify_multiplexer etc. > > And we usually use unsigned type for offset. We will fix this in next version. > > >> +    bool msi_enabled; >> +    /* Name strings for interrupts. */ >> +    char (*vm_vq_names)[256]; >>   }; >>     struct virtio_mmio_vq_info { >> @@ -101,6 +107,8 @@ struct virtio_mmio_vq_info { >>   }; >>     +static void vm_free_msi_irqs(struct virtio_device *vdev); >> +static int vm_request_msi_vectors(struct virtio_device *vdev, int >> nirqs); >>     /* Configuration interface */ >>   @@ -273,12 +281,28 @@ static bool vm_notify(struct virtqueue *vq) >>   { >>       struct virtio_mmio_device *vm_dev = >> to_virtio_mmio_device(vq->vdev); >>   +    if (vm_dev->version == 3) { >> +        int offset = vm_dev->doorbell_base + >> +                 vm_dev->doorbell_scale * vq->index; >> +        writel(vq->index, vm_dev->base + offset); > > > In virtio-pci we store the doorbell address in vq->priv to avoid doing > multiplication in fast path. Good suggestion. We will fix this in next version. [...] >> + >> +static int vm_request_msi_vectors(struct virtio_device *vdev, int >> nirqs) >> +{ >> +    struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev); >> +    int irq, err; >> +    u16 csr = readw(vm_dev->base + VIRTIO_MMIO_MSI_STATUS); >> + >> +    if (vm_dev->msi_enabled || (csr & VIRTIO_MMIO_MSI_ENABLE_MASK) >> == 0) >> +        return -EINVAL; >> + >> +    vm_dev->vm_vq_names = kmalloc_array(nirqs, >> sizeof(*vm_dev->vm_vq_names), >> +            GFP_KERNEL); >> +    if (!vm_dev->vm_vq_names) >> +        return -ENOMEM; >> + >> +    if (!vdev->dev.msi_domain) >> +        vdev->dev.msi_domain = platform_msi_get_def_irq_domain(); >> +    err = platform_msi_domain_alloc_irqs(&vdev->dev, nirqs, >> +            mmio_write_msi_msg); > > > Can platform_msi_domain_alloc_irqs check msi_domain vs NULL? > Actually here, we need to firstly consider the cases that @dev doesn't have @msi_domain, according to the report by lkp. For the platform_msi_domain_alloc_irqs, it can help check inside. > [...] >>         rc = register_virtio_device(&vm_dev->vdev); >>       if (rc) >> @@ -619,8 +819,6 @@ static int virtio_mmio_remove(struct >> platform_device *pdev) >>       return 0; >>   } >>   - >> - > > > Unnecessary changes. Got it. Will remove it later. > [...] >>   +/* MSI related registers */ >> + >> +/* MSI status register */ >> +#define VIRTIO_MMIO_MSI_STATUS        0x0c0 >> +/* MSI command register */ >> +#define VIRTIO_MMIO_MSI_COMMAND        0x0c2 >> +/* MSI low 32 bit address, 64 bits in two halves */ >> +#define VIRTIO_MMIO_MSI_ADDRESS_LOW    0x0c4 >> +/* MSI high 32 bit address, 64 bits in two halves */ >> +#define VIRTIO_MMIO_MSI_ADDRESS_HIGH    0x0c8 >> +/* MSI data */ >> +#define VIRTIO_MMIO_MSI_DATA        0x0cc > > > I wonder what's the advantage of using registers instead of memory > mapped tables as PCI did. Is this because MMIO doesn't have capability > list which makes it hard to be extended if we have variable size of > tables? > Yes, mmio doesn't have capability which limits the extension. It need some registers to specify the msi table/mask table/pending table offsets if using what pci did. As comments previously, mask/pending can be easily extended by MSI command. > >> + >> +/* RO: MSI feature enabled mask */ >> +#define VIRTIO_MMIO_MSI_ENABLE_MASK    0x8000 >> +/* RO: Maximum queue size available */ >> +#define VIRTIO_MMIO_MSI_STATUS_QMASK    0x07ff >> +/* Reserved */ >> +#define VIRTIO_MMIO_MSI_STATUS_RESERVED    0x7800 >> + >> +#define VIRTIO_MMIO_MSI_CMD_UPDATE    0x1 > > > I believe we need a command to read the number of vectors supported by > the device, or 2048 is assumed to be a fixed size here? For not bringing much complexity, we proposed vector per queue and fixed relationship between events and vectors. So the number of vectors supported by device is equal to the total number of vqs and config. We will try to explicitly highlight this point in spec for later version. Thanks! Jing > > --------------------------------------------------------------------- > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org >