qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]