From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux-foundation.org,
virtualization@lists.linux-foundation.org,
linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org,
rjw@rjwysocki.net, lenb@kernel.org, lorenzo.pieralisi@arm.com,
guohanjun@huawei.com, sudeep.holla@arm.com,
gregkh@linuxfoundation.org, joro@8bytes.org, bhelgaas@google.com,
jasowang@redhat.com, jacob.jun.pan@intel.com,
eric.auger@redhat.com, sebastien.boeuf@intel.com,
kevin.tian@intel.com
Subject: Re: [RFC 13/13] iommu/virtio: Add topology description to
Date: Mon, 25 Nov 2019 18:48:17 +0100 [thread overview]
Message-ID: <20191125174817.GB945122@lophozonia> (raw)
In-Reply-To: <20191122072753-mutt-send-email-mst@kernel.org>
On Fri, Nov 22, 2019 at 07:53:19AM -0500, Michael S. Tsirkin wrote:
> Overall this looks good to me. The only point is that
> I think the way the interface is designed makes writing
> the driver a bit too difficult. Idea: if instead we just
> have a length field and then an array of records
> (preferably unions so we don't need to work hard),
> we can shadow that into memory, then iterate over
> the unions.
>
> Maybe add a uniform record length + number of records field.
> Then just skip types you do not know how to handle.
> This will also help make sure it's within bounds.
>
> What do you think?
Sounds good, that should simplify the implementation a bit.
> You will need to do something to address the TODO I think.
Yes, I'll try to figure out a way to test platform devices.
> > +static void viommu_cwrite(struct pci_dev *dev, int cfg,
> > + struct viommu_cap_config *cap, u32 length, u32 offset,
> > + u32 val)
>
> A single user with 4 byte parameter. Just open-code?
Ok
> > + cap.head.type = viommu_cread(dev, pci_cfg, dev_cfg, 2, offset);
> > + cap.head.next = viommu_cread(dev, pci_cfg, dev_cfg, 2, offset + 2);
>
> All of this doesn't seem to be endian-clean. Try running sparse I think
> it will complain.
It does, I'll fix this
> > @@ -36,6 +37,31 @@ struct virtio_iommu_config {
> > struct virtio_iommu_range_32 domain_range;
> > /* Probe buffer size */
> > __le32 probe_size;
> > + /* Offset to the beginning of the topology table */
> > + __le16 topo_offset;
>
> why do we need an offset?
I find it awkward to put a variable-size array in the middle of the
config. The virtio_iommu_config struct would be easier to extend later if
we keep the array at the end and only define small static fields here.
>
> > +};
> > +
> > +struct virtio_iommu_topo_head {
> > + __le16 type;
> > + __le16 next;
> > +};
>
> So this linked list makes things harder than necessary imho.
> It will be easier to just have a counter with # of records.
> Then make all records the same size.
> Then just read each record out into a buffer, and
> handle it there.
Yes, that should simplify things.
Thanks,
Jean
next prev parent reply other threads:[~2019-11-25 17:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-22 10:49 [RFC 00/13] virtio-iommu on non-devicetree platforms Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 01/13] ACPI/IORT: Move IORT to the ACPI folder Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 02/13] ACPI: Add VIOT definitions Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 03/13] ACPI/IORT: Allow registration of external tables Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 04/13] ACPI/IORT: Add node categories Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 05/13] ACPI/IORT: Support VIOT virtio-mmio node Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 06/13] ACPI/IORT: Support VIOT virtio-pci node Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 07/13] ACPI/IORT: Defer probe until virtio-iommu-pci has registered a fwnode Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 08/13] ACPI/IORT: Add callback to update a device's fwnode Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 09/13] iommu/virtio: Create fwnode if necessary Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 10/13] iommu/virtio: Update IORT fwnode Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC 11/13] ACPI: Add VIOT table Jean-Philippe Brucker
2019-11-22 10:49 ` [RFC virtio 12/13] virtio-iommu: Add built-in topology description Jean-Philippe Brucker
2019-11-22 10:50 ` [RFC 13/13] iommu/virtio: Add topology description to Jean-Philippe Brucker
2019-11-22 12:53 ` Michael S. Tsirkin
2019-11-25 17:48 ` Jean-Philippe Brucker [this message]
2019-11-22 13:00 ` [RFC 00/13] virtio-iommu on non-devicetree platforms Michael S. Tsirkin
2019-11-25 17:53 ` Jean-Philippe Brucker
2019-11-23 0:01 ` Jacob Pan (Jun)
2019-11-25 18:02 ` Jean-Philippe Brucker
2019-12-04 3:01 ` Jacob Pan (Jun)
2019-12-18 11:20 ` Jean-Philippe Brucker
2019-12-20 18:54 ` Jacob Pan (Jun)
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=20191125174817.GB945122@lophozonia \
--to=jean-philippe@linaro.org \
--cc=bhelgaas@google.com \
--cc=eric.auger@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=guohanjun@huawei.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=jasowang@redhat.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mst@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=sebastien.boeuf@intel.com \
--cc=sudeep.holla@arm.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
/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).