> From: Xu, Quan
> Sent: Tuesday, December 22, 2015 6:26 PM
>
> > On 22.12.2015 at 5:09pm, wrote:
> > >>> On 22.12.15 at 09:43, wrote:
> > > Let's finish our discussion. I accept your idea. But I need to
> > > separate it into 3 patch set (It is complicated for me, sometime it makes
> > > me
>
> On 22.12.2015 at 5:09pm, wrote:
> >>> On 22.12.15 at 09:43, wrote:
> > Let's finish our discussion. I accept your idea. But I need to
> > separate it into 3 patch set (It is complicated for me, sometime it makes me
> crash.):
> >Patch set 1: Device-TLB/iotlb flush error. (send out this wee
> On 22.12.2015 at 5:09pm, wrote:
> >>> On 22.12.15 at 09:43, wrote:
> > Let's finish our discussion. I accept your idea. But I need to
> > separate it into 3 patch set (It is complicated for me, sometime it makes me
> crash.):
> >Patch set 1: Device-TLB/iotlb flush error. (send out this wee
>>> On 22.12.15 at 09:43, wrote:
> Let's finish our discussion. I accept your idea. But I need to separate it
> into 3 patch set (It is complicated for me, sometime it makes me crash.):
>Patch set 1: Device-TLB/iotlb flush error. (send out this week)
>Patch set 2: context flush error. (
> On December 22, 2015 4:27pm, wrote:
> >>> On 22.12.15 at 09:10, wrote:
> > For Device-TLB flush error, I think we need to propagated error code.
> > For IEC/iotlb/context flush error, if panic is acceptable, we can
> > ignore the propagated error code. BTW, it is very challenge / tricky
> > to
>>> On 22.12.15 at 09:10, wrote:
> For Device-TLB flush error, I think we need to propagated error code.
> For IEC/iotlb/context flush error, if panic is acceptable, we can ignore the
> propagated error code. BTW, it is very challenge / tricky to handle all
> Of error, and some error is unrecover
e.dun...@eu.citrix.com' ; Nakajima, Jun
>> ; Tian, Kevin ; 'xen-
>> de...@lists.xen.org' ; 'k...@xen.org'
>> ;
>> 't...@xen.org'
>> Subject: RE: [Xen-devel] [PATCH v3 0/2] VT-d flush issue
>>
>> >>> On 22.12
>On 22.12.2015 at 4:01pm wrote:
> >>> On 22.12.15 at 08:40, wrote:
> > Maybe, there are still some misunderstanding about your expectation.
> > Let me summarize it here.
> >
> > After Quan's patch-set, there are two types of error code:
> > - -EOPNOTSUPP
> > Now we only support and use software w
27;xen-
> de...@lists.xen.org' ; 'k...@xen.org' ;
> 't...@xen.org'
> Subject: RE: [Xen-devel] [PATCH v3 0/2] VT-d flush issue
>
> >>> On 22.12.15 at 08:40, wrote:
> > Maybe, there are still some misunderstanding about your expecta
>>> On 22.12.15 at 08:40, wrote:
> Maybe, there are still some misunderstanding about your expectation.
> Let me summarize it here.
>
> After Quan's patch-set, there are two types of error code:
> - -EOPNOTSUPP
> Now we only support and use software way to synchronize the invalidation,
> if someo
'xen-devel@lists.xen.org' ;
> 'k...@xen.org' ; 't...@xen.org'
> Subject: RE: [Xen-devel] [PATCH v3 0/2] VT-d flush issue
>
> >>> On 21.12.15 at 14:08, wrote:
> >> On 21.12.2015 at 8:50pm, wrote:
> >> >>> On 21.12.15 a
>On 21.12.2015 at 10:53pm, wrote:
> >>> On 21.12.15 at 15:31, wrote:
> >> On 21.12.2015 at 10:16pm, wrote:
> >> >>> On 21.12.15 at 15:08, wrote:
> >> >> On 21.12.2015 at 9:23pm, wrote:
> >> >> >>> On 21.12.15 at 14:08, wrote:
> >> >> >> On 21.12.2015 at 8:50pm, wrote:
> >> >> >> >>> On 21
>>> On 21.12.15 at 15:31, wrote:
>> On 21.12.2015 at 10:16pm, wrote:
>> >>> On 21.12.15 at 15:08, wrote:
>> >> On 21.12.2015 at 9:23pm, wrote:
>> >> >>> On 21.12.15 at 14:08, wrote:
>> >> >> On 21.12.2015 at 8:50pm, wrote:
>> >> >> >>> On 21.12.15 at 13:28, wrote:
>> >> >> > On 21.12.2015
> On 21.12.2015 at 10:16pm, wrote:
> >>> On 21.12.15 at 15:08, wrote:
> >> On 21.12.2015 at 9:23pm, wrote:
> >> >>> On 21.12.15 at 14:08, wrote:
> >> >> On 21.12.2015 at 8:50pm, wrote:
> >> >> >>> On 21.12.15 at 13:28, wrote:
> >> >> > On 21.12.2015 at 7:47pm, wrote:
> >> >> >> >>> On 20.1
>>> On 21.12.15 at 15:08, wrote:
>> On 21.12.2015 at 9:23pm, wrote:
>> >>> On 21.12.15 at 14:08, wrote:
>> >> On 21.12.2015 at 8:50pm, wrote:
>> >> >>> On 21.12.15 at 13:28, wrote:
>> >> > On 21.12.2015 at 7:47pm, wrote:
>> >> >> >>> On 20.12.15 at 14:57, wrote:
>
> 1.
>> >> > IMO, When
> On 21.12.2015 at 9:23pm, wrote:
> >>> On 21.12.15 at 14:08, wrote:
> >> On 21.12.2015 at 8:50pm, wrote:
> >> >>> On 21.12.15 at 13:28, wrote:
> >> > On 21.12.2015 at 7:47pm, wrote:
> >> >> >>> On 20.12.15 at 14:57, wrote:
1.
> >> > IMO, When VT-d is enabled, but is not working correct. T
> On 21.12.2015 at 9:23pm, wrote:
> >>> On 21.12.15 at 14:08, wrote:
> >> On 21.12.2015 at 8:50pm, wrote:
> >> >>> On 21.12.15 at 13:28, wrote:
> >> > On 21.12.2015 at 7:47pm, wrote:
> >> >> >>> On 20.12.15 at 14:57, wrote:
> >> >> > 2. If VT-d is bug, does the hardware_domain continue to wo
>>> On 21.12.15 at 14:08, wrote:
>> On 21.12.2015 at 8:50pm, wrote:
>> >>> On 21.12.15 at 13:28, wrote:
>> > On 21.12.2015 at 7:47pm, wrote:
>> >> >>> On 20.12.15 at 14:57, wrote:
>> >> > 2. If VT-d is bug, does the hardware_domain continue to work with
>> >> > PCIe Devices / DRAM well with D
> On 21.12.2015 at 8:50pm, wrote:
> >>> On 21.12.15 at 13:28, wrote:
> > On 21.12.2015 at 7:47pm, wrote:
> >> >>> On 20.12.15 at 14:57, wrote:
> >> > 2. If VT-d is bug, does the hardware_domain continue to work with
> >> > PCIe Devices / DRAM well with DMA remapping error?
> >> >I think it
>>> On 21.12.15 at 13:28, wrote:
> On 21.12.2015 at 7:47pm, wrote:
>> >>> On 20.12.15 at 14:57, wrote:
>> > 2. If VT-d is bug, does the hardware_domain continue to work with PCIe
>> > Devices / DRAM well with DMA remapping error?
>> >I think it is no. furthermore, i think VMM can NOT run a n
On 21.12.2015 at 7:47pm, wrote:
> >>> On 20.12.15 at 14:57, wrote:
> > 2. If VT-d is bug, does the hardware_domain continue to work with
> > PCIe Devices / DRAM well with DMA remapping error?
> >I think it is no. furthermore, i think VMM can NOT run a normal
> > HVM domain without device-pa
On 21.12.2015 at 7:47pm, wrote:
> >>> On 20.12.15 at 14:57, wrote:
> > 2. If VT-d is bug, does the hardware_domain continue to work with PCIe
> > Devices / DRAM well with DMA remapping error?
> >I think it is no. furthermore, i think VMM can NOT run a normal HVM
> > domain without device-pass
>>> On 20.12.15 at 14:57, wrote:
> 2. If VT-d is bug, does the hardware_domain continue to work with PCIe
> Devices / DRAM well with DMA remapping error?
>I think it is no. furthermore, i think VMM can NOT run a normal HVM
> domain without device-passthrough.
In addition to what Andrew said
On 20/12/15 13:57, Xu, Quan wrote:
>> On 12.12.2015 at 9:22pm, wrote:
>> This patches are based on Kevin Tian's previous discussion 'Revisit
>> VT-d asynchronous flush issue'.
>> Fix current timeout concern and also allow limited ATS support in a light
>> way:
>
>> 2. Fix vt-d flush timeout iss
>On 12.12.2015 at 9:22pm, wrote:
> This patches are based on Kevin Tian's previous discussion 'Revisit
>VT-d asynchronous flush issue'.
> Fix current timeout concern and also allow limited ATS support in a light way:
> 2. Fix vt-d flush timeout issue.
>
> If IOTLB/Context/IETC flush is t
>On 12.12.2015 at 9:22pm, wrote:
> This patches are based on Kevin Tian's previous discussion 'Revisit VT-d
> asynchronous flush issue'.
> Fix current timeout concern and also allow limited ATS support in a light way:
> 2. Fix vt-d flush timeout issue.
>
> If IOTLB/Context/IETC flush is tim
This patches are based on Kevin Tian's previous discussion 'Revisit VT-d
asynchronous flush issue'.
Fix current timeout concern and also allow limited ATS support in a light way:
1. Reduce spin timeout to 1ms, which can be boot-time changed with
'iommu_qi_timeout_ms'.
For example:
27 matches
Mail list logo
