[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue.
>>> On 13.01.16 at 07:12, <kevin.tian@xxxxxxxxx> wrote: >> From: Xu, Quan >> Sent: Thursday, January 07, 2016 9:47 PM >> >> > On January 07, 2016 9:28 PM, <JBeulich@xxxxxxxx> wrote: >> > >>> On 07.01.16 at 02:39, <quan.xu@xxxxxxxxx> wrote: >> > > On January 06, 2016 7:26 PM, <quan.xu@xxxxxxxxx> wrote: >> > >> > I didn't think about the full logic thoroughly now. But it would >> > >> > always be good to not hide device now until a point where all >> > >> > related states have been cleaned up in error handling path chained up. >> > >> > >> > > >> > > Jan, could you help me to double check it? thanks. >> > >> > I'm not sure I understand what you want or need, the more that I didn't > even >> > get around to look at the patches yet. >> > >> >> Jan, >> Patch 2/3 and Patch 3/3 are based on v3 (Actually they are v3's patch 1/2 > and patch 2/2). >> We have discussed how to hide a device with pci_hide_device() when >> Device-TLB > flush is >> error. >> >> Now there are 2 concerns: >> 1. Hide the PCI device may break the code path. (then the pdev->domain > is >> dom_xen) >> 2. Is the blew logic right? >> --If Device-TLB flush is timeout, we'll hide the target ATS >> device > and crash the >> domain owning this ATS device. >> If impacted domain is hardware domain, just throw out a > warning, instead of >> crash the hardware domain. >> The hided Device will be disallowed to be further assigned to > any domain. >> >> Kevin, correct me if I am wrong. >> >> > > for 2, yes it's the policy we agreed in previous discussion. > > for 1, after more thinking I think the concern is real. pci_hide_device > is used once in early boot-up phase. At that time, it's simple to just > have right owner configured. However in the path of normal device > assign/deassign, there are tons of more state associated which may > be related to the owner. Though we may do some special handling > in related code paths to have dom_xen specially handled, it's way > tricky and not easy to maintain. I don't buy this without one of you pointing out the actual difficulties: The domain is being crashed anyway, so there's no true device de-assignment needed (IOMMU tables will get torn down no matter what). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |