[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 1/7] VT-d: Check VT-d Device-TLB flush error(IOMMU part).



> On February 17, 2016 9:05pm, <JBeulich@xxxxxxxx> wrote:
> >>> On 17.02.16 at 13:49, <quan.xu@xxxxxxxxx> wrote:
> >>  On February 16, 2016 7:06pm, <JBeulich@xxxxxxxx> wrote:
> >> >>> On 16.02.16 at 11:50, <quan.xu@xxxxxxxxx> wrote:
> >> >>  On February 11, 2016 at 1:01am, <JBeulich@xxxxxxxx> wrote:
> >> >> >>> On 05.02.16 at 11:18, <quan.xu@xxxxxxxxx> wrote:
> >
> >> >> > @@ -369,12 +376,16 @@ void iommu_share_p2m_table(struct
> domain*
> >> d)
> >> >> >          ops->share_p2m(d);
> >> >> >  }
> >> >> >
> >> >> > -void iommu_crash_shutdown(void)
> >> >> > +int iommu_crash_shutdown(void)
> >> >> >  {
> >> >> >      const struct iommu_ops *ops = iommu_get_ops();
> >> >> > +
> >> >> >      if ( iommu_enabled )
> >> >> > -        ops->crash_shutdown();
> >> >> > +        return ops->crash_shutdown();
> >> >> > +
> >> >> >      iommu_enabled = iommu_intremap = 0;
> >> >> > +
> >> >> > +    return 0;
> >> >> >  }
> >> >>
> >> >> Here again the question is - what is the error value going to be
> >> >> used for? We're trying to shut down a crashed system when coming here.
> >> >>
> >> >  I tried to clean up in error handling path chained up. It logs an
> >> > error message,  When it calls iommu_crash_shutdown() and returns a
> >> > non-zero value [in patch 2/7].
> >>
> >> That sounds okay than (I didn't get around to look at patches 2-7
> >> yet), but
> > is
> >> somewhat contrary to me request of adding __must_check as far as
> >> possible, which - if done here - would break the build without also
> >> adjusting the
> > caller(s).
> >>
> >
> >
> > If they are in the same patch set, I think it is acceptable.
> 
> If unavoidable, yes. But please remember that patch series don't necessarily 
> get
> committed in one go.
> 
> > BTW, with patch 1/7, I can build Xen successfully( make xen ).
> > To align this rule, I'd better merge patch1/7 and patch 2/7 into a
> > large patch.
> 
> Not having looked at patch 2 yet
> (I'm about to), 

Good news. :):)
I think there are maybe some minor issues for this patch set ( _my_estimate_), 
and I will address these issues immediately.


> I can't tell whether this makes
> sense. I'd rather not see large patches become even larger though - please
> make a reasonable attempt at splitting things (in the case here for example by
> adjusting top level functions first, working your way down to leaf ones, thus
> guaranteeing that newly added __must_check annotations will be properly
> honored at each patch boundary).
> 

Okay, I will try to do it in v6. Thanks.


Quan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.