Re: [Xen-devel] [PATCH v4 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue.

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Monday, January 18, 2016 11:32 PM
> 
> At 10:46 +0000 on 14 Jan (1452768377), Xu, Quan wrote:
> > > It's not about how this specific thing can be fixed. I didn't check all 
> > > the code.
> > > There could be more examples, and in the future all new code need to be 
> > > aware
> > > that the majority of IOMMU functions may have pdev->domain changed due to
> > > error. My concern is more that it's not a good design. I think it's 
> > > natural to have
> > > a state changed only after all existing references in the call chain have 
> > > been
> > > completed. Adding a new flag to delay hiding device looks much clearer to 
> > > me.
> >
> > It looks we are not on the same page for how to hide a device.
> > Actually I have implemented these two ideas with pci_hide_device()
> > or flag in previous versions.
> >
> > Andrew and Tim, what's your opinion?
> 
> I have no strong opinion, since this isn't my area (and really never
> was - I worked on address translation more than device allocation).
> Since you ask, I don't see anything wrong with hiding the device if
> you already own all the locks, and I'd be inclined to make whatever
> changes are necessary ASAP after the error.  Deferring the change (and
> having all callers need to look for the deferred error) sounds
> fragile.
> 

It doesn't need to have all callers do same deferred error check. It
can be done in next device assignment point. But I'm OK with going
Jan's proposal, i.e. hide device right when thing goes wrong, as long
as it is the common practice in Xen.

Thanks
Kevin

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