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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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