All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: "Zhang, Qi1" <qi1.zhang@intel.com>
Cc: "ehabkost@redhat.com" <ehabkost@redhat.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"Qi, Yadong" <yadong.qi@intel.com>,
	"rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [PATCH V2] intel_iommu: TM field should not be in reserved bits
Date: Fri, 27 Sep 2019 17:32:23 +0800	[thread overview]
Message-ID: <20190927093223.GC9412@xz-x1> (raw)
In-Reply-To: <215440059103624D9AD9D1DCACBF45DD3E84E270@shsmsx102.ccr.corp.intel.com>

On Fri, Sep 27, 2019 at 08:03:21AM +0000, Zhang, Qi1 wrote:
> 
> 
> > -----Original Message-----
> > From: Peter Xu <peterx@redhat.com>
> > Sent: Friday, September 27, 2019 2:10 PM
> > To: Zhang, Qi1 <qi1.zhang@intel.com>
> > Cc: qemu-devel@nongnu.org; ehabkost@redhat.com; mst@redhat.com;
> > pbonzini@redhat.com; rth@twiddle.net
> > Subject: Re: [PATCH V2] intel_iommu: TM field should not be in reserved bits
> > 
> > On Fri, Sep 27, 2019 at 12:58:38PM +0800, qi1.zhang@intel.com wrote:
> > > From: "Zhang, Qi" <qi1.zhang@intel.com>
> > >
> > > When dt is supported, TM field should not be Reserved(0).
> > >
> > > Refer to VT-d Spec 9.8
> > >
> > > Signed-off-by: Zhang, Qi <qi1.zhang@intel.com>
> > > Signed-off-by: Qi, Yadong <yadong.qi@intel.com>
> > > ---
> > >  hw/i386/intel_iommu.c          | 12 ++++++------
> > >  hw/i386/intel_iommu_internal.h | 25 +++++++++++++++++++------
> > >  2 files changed, 25 insertions(+), 12 deletions(-)
> > > ---
> > > Changelog V2:
> > >  move dt_supported flag to VTD_SPTE_PAGE_LX_RSVD_MASK and
> > > VTD_SPTE_LPAGE_LX_RSVD_MASK
> > >
> > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index
> > > f1de8fdb75..35222cf55c 100644
> > > --- a/hw/i386/intel_iommu.c
> > > +++ b/hw/i386/intel_iommu.c
> > > @@ -3548,13 +3548,13 @@ static void vtd_init(IntelIOMMUState *s)
> > >       * Rsvd field masks for spte
> > >       */
> > >      vtd_paging_entry_rsvd_field[0] = ~0ULL;
> > > -    vtd_paging_entry_rsvd_field[1] = VTD_SPTE_PAGE_L1_RSVD_MASK(s-
> > >aw_bits);
> > > -    vtd_paging_entry_rsvd_field[2] = VTD_SPTE_PAGE_L2_RSVD_MASK(s-
> > >aw_bits);
> > > -    vtd_paging_entry_rsvd_field[3] = VTD_SPTE_PAGE_L3_RSVD_MASK(s-
> > >aw_bits);
> > > +    vtd_paging_entry_rsvd_field[1] = VTD_SPTE_PAGE_L1_RSVD_MASK(s-
> > >aw_bits, x86_iommu->dt_supported);
> > > +    vtd_paging_entry_rsvd_field[2] = VTD_SPTE_PAGE_L2_RSVD_MASK(s-
> > >aw_bits, x86_iommu->dt_supported);
> > > +    vtd_paging_entry_rsvd_field[3] =
> > > + VTD_SPTE_PAGE_L3_RSVD_MASK(s->aw_bits, x86_iommu-
> > >dt_supported);
> > >      vtd_paging_entry_rsvd_field[4] = VTD_SPTE_PAGE_L4_RSVD_MASK(s-
> > >aw_bits);
> > > -    vtd_paging_entry_rsvd_field[5] = VTD_SPTE_LPAGE_L1_RSVD_MASK(s-
> > >aw_bits);
> > > -    vtd_paging_entry_rsvd_field[6] = VTD_SPTE_LPAGE_L2_RSVD_MASK(s-
> > >aw_bits);
> > > -    vtd_paging_entry_rsvd_field[7] = VTD_SPTE_LPAGE_L3_RSVD_MASK(s-
> > >aw_bits);
> > > +    vtd_paging_entry_rsvd_field[5] =
> > VTD_SPTE_LPAGE_L1_RSVD_MASK(s->aw_bits, x86_iommu-
> > >dt_supported);
> > > +    vtd_paging_entry_rsvd_field[6] =
> > VTD_SPTE_LPAGE_L2_RSVD_MASK(s->aw_bits, x86_iommu-
> > >dt_supported);
> > > +    vtd_paging_entry_rsvd_field[7] =
> > > + VTD_SPTE_LPAGE_L3_RSVD_MASK(s->aw_bits, x86_iommu-
> > >dt_supported);
> > >      vtd_paging_entry_rsvd_field[8] =
> > > VTD_SPTE_LPAGE_L4_RSVD_MASK(s->aw_bits);
> > 
> > Should this TM bit only affects leaves?  Say, entry 1 (4K), 5 (2M), 6 (1G).
> > While this reminded me that I'm totally confused on why we have had entry
> > 7, 8 after all...  Are they really used?
> Yes. TM bit only affects. To this array, index 1, 5,6,7 may be leaf. Will update a new patchset for it.

Could I ask why index 7 may be leaf?

> > 
> > >
> > >      if (x86_iommu_ir_supported(x86_iommu)) { diff --git
> > > a/hw/i386/intel_iommu_internal.h b/hw/i386/intel_iommu_internal.h
> > > index c1235a7063..01f1aa6c86 100644
> > > --- a/hw/i386/intel_iommu_internal.h
> > > +++ b/hw/i386/intel_iommu_internal.h
> > > @@ -387,19 +387,31 @@ typedef union VTDInvDesc VTDInvDesc;  #define
> > > VTD_INV_DESC_DEVICE_IOTLB_RSVD_LO 0xffff0000ffe0fff8
> > >
> > >  /* Rsvd field masks for spte */
> > > -#define VTD_SPTE_PAGE_L1_RSVD_MASK(aw) \
> > > +#define VTD_SPTE_PAGE_L1_RSVD_MASK(aw, dt_supported) \
> > > +        dt_supported? \
> > > +        (0x800ULL | ~(VTD_HAW_MASK(aw) | VTD_SL_IGN_COM |
> > VTD_SL_TM))
> > > +: \
> > >          (0x800ULL | ~(VTD_HAW_MASK(aw) | VTD_SL_IGN_COM))
> > 
> > This seems strange too in that ~VTD_HAW_MASK(aw) probably covered bits
> > 63-48 for aw==48 case so it should already cover VTD_SL_TM?
> VTD_SL_IGN_COM 0xbff0000000000000ULL, TM field is cleared by ~ VTD_SL_IGN_COM
> > 
> > Meanwhile when I'm reading the spec I see at least bits 61-52 ignored rather
> > than reserved.
> Yes. Bit 61~52 is ignored. Such as the index 5 of this array is 0xfff8000000800.

Oops, my poor eye obviously didn't see that the "~" operator is
applied over the whole (VTD_HAW_MASK(aw) | VTD_SL_IGN_COM)... :)

Btw, you should only touch up the macros that are leaves here.
Non-leaves should still keep that bit as reserved.

Thanks,

-- 
Peter Xu


  reply	other threads:[~2019-09-27  9:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-27  4:58 [PATCH V2] intel_iommu: TM field should not be in reserved bits qi1.zhang
2019-09-27  6:10 ` Peter Xu
2019-09-27  8:03   ` Zhang, Qi1
2019-09-27  9:32     ` Peter Xu [this message]
2019-09-29  1:11       ` Zhang, Qi1
2019-09-29  2:02         ` Peter Xu
2019-09-29  2:10           ` Zhang, Qi1
2019-09-29  2:19           ` Peter Xu
2019-09-27  9:33 ` Michael S. Tsirkin
2019-09-27 20:44 ` no-reply

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=20190927093223.GC9412@xz-x1 \
    --to=peterx@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qi1.zhang@intel.com \
    --cc=rth@twiddle.net \
    --cc=yadong.qi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.