[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 04/10] intel_iommu: Second Stage Access Dirty bit support
From: |
Jason Wang |
Subject: |
Re: [PATCH RFC 04/10] intel_iommu: Second Stage Access Dirty bit support |
Date: |
Thu, 5 May 2022 15:41:03 +0800 |
On Wed, May 4, 2022 at 4:47 AM Joao Martins <joao.m.martins@oracle.com> wrote:
>
> On 4/29/22 19:21, Peter Xu wrote:
> > On Fri, Apr 29, 2022 at 10:12:01AM +0100, Joao Martins wrote:
> >> On 4/29/22 03:26, Jason Wang wrote:
> >>> On Fri, Apr 29, 2022 at 5:14 AM Joao Martins <joao.m.martins@oracle.com>
> >>> wrote:
> >>>> @@ -3693,7 +3759,8 @@ static void vtd_init(IntelIOMMUState *s)
> >>>>
> >>>> /* TODO: read cap/ecap from host to decide which cap to be exposed.
> >>>> */
> >>>> if (s->scalable_mode) {
> >>>> - s->ecap |= VTD_ECAP_SMTS | VTD_ECAP_SRS | VTD_ECAP_SLTS;
> >>>> + s->ecap |= VTD_ECAP_SMTS | VTD_ECAP_SRS | VTD_ECAP_SLTS |
> >>>> + VTD_ECAP_SLADS;
> >>>> }
> >>>
> >>> We probably need a dedicated command line parameter and make it compat
> >>> for pre 7.1 machines.
> >>>
> >>> Otherwise we may break migration.
> >>
> >> I can gate over an 'x-ssads' option (default disabled). Which reminds me
> >> that I probably
> >> should rename to the most recent mnemonic (as SLADS no longer exists in
> >> manuals).
> >>
> >> If we all want by default enabled I can add a separate patch to do so.
> >
> > The new option sounds good.
> >
>
> OK, I'll fix it then for the next iteration.
>
> Also, perhaps I might take the emulated iommu patches out of the iommufd
> stuff into a
> separate series. There might be a place for them in the realm of
> testing/prototyping.
That would be better.
>
> > Jason, per our previous discussion, shall we not worry about the
> > compatibility issues per machine-type until the whole feature reaches a
> > mostly-complete stage?
> >
> > There seems to have a bunch of sub-features for scalable mode and it's a
> > large project as a whole. I'm worried trying to maintain compatibilities
> > for all the small sub-features could be an unnessary burden to the code
> > base.
My understanding, if it's not too hard, it looks better for each
sub-features to try its best for compatibility. For this case, having
a dedicated option might help for debugging as well.
> Perhaps best to see how close we are to spec is to check what we support in
> intel-iommu
> in terms of VT-d revision versus how many buckets we fill in. I think
> SLADS/SSADS was in
> 3.0 IIRC.
>
> I can take the compat stuff out if it's too early for that -- But I take it
> these are questions for Jason.
>
There's probably no need for the compat stuff, having a dedicated
option and making it disabled by default should be fine.
Thanks