From: Peter Xu <peterx@redhat.com>
To: Yi Sun <yi.y.sun@linux.intel.com>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, rth@twiddle.net,
ehabkost@redhat.com, mst@redhat.com, marcel.apfelbaum@gmail.com,
kevin.tian@intel.com, yi.l.liu@intel.com, yi.y.sun@intel.com
Subject: Re: [Qemu-devel] [RFC v1 2/3] intel_iommu: add 256 bits qi_desc support
Date: Tue, 12 Feb 2019 14:27:28 +0800 [thread overview]
Message-ID: <20190212062728.GK1011@xz-x1> (raw)
In-Reply-To: <1548824953-23413-3-git-send-email-yi.y.sun@linux.intel.com>
On Wed, Jan 30, 2019 at 01:09:12PM +0800, Yi Sun wrote:
> From: "Liu, Yi L" <yi.l.liu@intel.com>
>
> Per Intel(R) VT-d 3.0, the qi_desc is 256 bits in Scalable
> Mode. This patch adds emulation of 256bits qi_desc.
>
> [Yi Sun is co-developer to rebase and refine the patch.]
> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
> Signed-off-by: Liu, Yi L <yi.l.liu@intel.com>
Same here; I think you should have your s-o-b last. ;)
> ---
> hw/i386/intel_iommu.c | 182 +++++++++++++++++++++++++----------------
> hw/i386/intel_iommu_internal.h | 8 +-
> include/hw/i386/intel_iommu.h | 1 +
> 3 files changed, 116 insertions(+), 75 deletions(-)
>
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index 396ac8e..3664a00 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -38,6 +38,7 @@
> #include "trace.h"
>
> #define vtd_devfn_check(devfn) ((devfn & VTD_DEVFN_CHECK_MASK) ? true : false)
> +#define vtd_ecap_smts(s) ((s)->ecap & VTD_ECAP_SMTS)
I'd prefer capital letters for macros. Your call.
>
> /* context entry operations */
> #define vtd_get_ce_size(s, ce) \
> @@ -65,6 +66,9 @@
> #define vtd_pe_get_slpt_base(pe) ((pe)->val[0] & VTD_SM_PASID_ENTRY_SLPTPTR)
> #define vtd_pe_get_domain_id(pe) VTD_SM_PASID_ENTRY_DID((pe)->val[1])
>
> +/* invalidation desc */
> +#define vtd_get_inv_desc_width(s) ((s)->iq_dw ? 32 : 16)
Nit: I'll prefer dropping all the "get" wordings in these macros to be
"vtd_inv_desc_width" since that "get" doesn't help much on
understanding its meanings. But it's personal preference too.
And since you've already have the iq_dw variable - why not store the
width directly into it? An uint8_t would suffice.
> +
> static void vtd_address_space_refresh_all(IntelIOMMUState *s);
> static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n);
>
> @@ -1759,6 +1763,11 @@ static void vtd_root_table_setup(IntelIOMMUState *s)
> s->root_scalable = s->root & VTD_RTADDR_SMT;
> s->root &= VTD_RTADDR_ADDR_MASK(s->aw_bits);
>
> + /* if Scalable mode is not enabled, enforce iq_dw to be 16 byte */
> + if (!s->root_scalable) {
> + s->iq_dw = 0;
This is ok but I feel it a bit awkward to change IQ setup specifically
in root table setup. You can simply do this:
- in vtd_init(), always set iq_dw=16. This will cover system resets
or IOMMU device reset, then
- only update iq_dw to 32 in vtd_mem_write() where guest specified
> + }
> +
> trace_vtd_reg_dmar_root(s->root, s->root_extended);
> }
>
> @@ -2052,7 +2061,7 @@ static void vtd_handle_gcmd_qie(IntelIOMMUState *s, bool en)
> if (en) {
> s->iq = iqa_val & VTD_IQA_IQA_MASK(s->aw_bits);
> /* 2^(x+8) entries */
> - s->iq_size = 1UL << ((iqa_val & VTD_IQA_QS) + 8);
> + s->iq_size = 1UL << ((iqa_val & VTD_IQA_QS) + 8 - (s->iq_dw ? 1 : 0));
> s->qi_enabled = true;
> trace_vtd_inv_qi_setup(s->iq, s->iq_size);
> /* Ok - report back to driver */
> @@ -2219,54 +2228,66 @@ static void vtd_handle_iotlb_write(IntelIOMMUState *s)
> }
>
> /* Fetch an Invalidation Descriptor from the Invalidation Queue */
> -static bool vtd_get_inv_desc(dma_addr_t base_addr, uint32_t offset,
> +static bool vtd_get_inv_desc(IntelIOMMUState *s,
> VTDInvDesc *inv_desc)
> {
> - dma_addr_t addr = base_addr + offset * sizeof(*inv_desc);
> - if (dma_memory_read(&address_space_memory, addr, inv_desc,
> - sizeof(*inv_desc))) {
> - error_report_once("Read INV DESC failed");
> - inv_desc->lo = 0;
> - inv_desc->hi = 0;
> + dma_addr_t base_addr = s->iq;
> + uint32_t offset = s->iq_head;
> + uint32_t dw = vtd_get_inv_desc_width(s);
> + dma_addr_t addr = base_addr + offset * dw;
> +
> + /* init */
> + inv_desc->val[0] = 0;
> + inv_desc->val[1] = 0;
> + inv_desc->val[2] = 0;
> + inv_desc->val[3] = 0;
No need?
> +
> + if (dma_memory_read(&address_space_memory, addr, inv_desc, dw)) {
> + error_report_once("Read INV DESC failed.");
> return false;
> }
> - inv_desc->lo = le64_to_cpu(inv_desc->lo);
> - inv_desc->hi = le64_to_cpu(inv_desc->hi);
> + inv_desc->val[0] = le64_to_cpu(inv_desc->val[0]);
> + inv_desc->val[1] = le64_to_cpu(inv_desc->val[1]);
> + inv_desc->val[2] = le64_to_cpu(inv_desc->val[2]);
> + inv_desc->val[3] = le64_to_cpu(inv_desc->val[3]);
Similar comments here on VTDInvDesc - you can keep the hi/lo fields,
but instead you can define the val[4] into the union too. Then:
if (dw == 16) {
inv_desc->lo = ...
inv_desc->hi = ...
} else {
inv_desc->val[0] = ...
inv_desc->val[1] = ...
inv_desc->val[2] = ...
inv_desc->val[3] = ...
}
Then this patch can be greatly simplified too since you don't need to
switch VTDInvDesc.{lo|hi} to val[0|1].
[...]
> @@ -2525,7 +2558,7 @@ static void vtd_handle_iqt_write(IntelIOMMUState *s)
> {
> uint64_t val = vtd_get_quad_raw(s, DMAR_IQT_REG);
>
> - s->iq_tail = VTD_IQT_QT(val);
> + s->iq_tail = VTD_IQT_QT(s->iq_dw, val);
You can check against bit 4 when iq_dw==32 and report error otherwise.
That's explicitly mentioned by the spec (chap 10.4.22).
> trace_vtd_inv_qi_tail(s->iq_tail);
>
> if (s->qi_enabled && !(vtd_get_long_raw(s, DMAR_FSTS_REG) & VTD_FSTS_IQE)) {
[...]
Regards,
--
Peter Xu
next prev parent reply other threads:[~2019-02-12 6:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-30 5:09 [Qemu-devel] [RFC v1 0/3] intel_iommu: support scalable mode Yi Sun
2019-01-30 5:09 ` [Qemu-devel] [RFC v1 1/3] intel_iommu: scalable mode emulation Yi Sun
2019-02-11 10:12 ` Peter Xu
2019-02-13 7:38 ` Yi Sun
2019-02-13 8:03 ` Peter Xu
2019-02-13 8:28 ` Peter Xu
2019-01-30 5:09 ` [Qemu-devel] [RFC v1 2/3] intel_iommu: add 256 bits qi_desc support Yi Sun
2019-02-12 6:27 ` Peter Xu [this message]
2019-02-13 9:00 ` Yi Sun
2019-02-13 10:42 ` Peter Xu
2019-02-14 1:52 ` Yi Sun
2019-02-14 3:24 ` Peter Xu
2019-02-14 6:27 ` Yi Sun
2019-02-14 7:13 ` Peter Xu
2019-02-14 7:35 ` Tian, Kevin
2019-02-14 8:13 ` Peter Xu
2019-02-14 8:22 ` Tian, Kevin
2019-02-14 8:43 ` Peter Xu
2019-01-30 5:09 ` [Qemu-devel] [RFC v1 3/3] intel_iommu: add scalable-mode option to make scalable mode work Yi Sun
2019-02-12 6:46 ` Peter Xu
2019-02-15 5:22 ` Yi Sun
2019-02-15 5:39 ` Peter Xu
2019-02-15 7:44 ` Yi Sun
2019-02-15 8:22 ` Jason Wang
2019-02-11 10:37 ` [Qemu-devel] [RFC v1 0/3] intel_iommu: support scalable mode Peter Xu
2019-02-13 5:46 ` Yi Sun
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=20190212062728.GK1011@xz-x1 \
--to=peterx@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kevin.tian@intel.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=yi.l.liu@intel.com \
--cc=yi.y.sun@intel.com \
--cc=yi.y.sun@linux.intel.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).