> On January 27, 2016 10:29pm, wrote:
> >>> On 27.01.16 at 15:13, wrote:
> >> On January 27, 2016 at 9:15pm, wrote:
> >> >>> On 27.01.16 at 13:38, wrote:
> >> >> On January 27, 2016 at 7:24pm, wrote:
> >> >> >>> On 27.01.16 at 12:09, wrote:
> >> >> >> On January 27, 2016 at 6:48am, wrote:
>>> On 27.01.16 at 15:13, wrote:
>> On January 27, 2016 at 9:15pm, wrote:
>> >>> On 27.01.16 at 13:38, wrote:
>> >> On January 27, 2016 at 7:24pm, wrote:
>> >> >>> On 27.01.16 at 12:09, wrote:
>> >> >> On January 27, 2016 at 6:48am, wrote:
>> >> >> > From: Jan Beulich [mailto:jbeul...@suse
> On January 27, 2016 at 9:15pm, wrote:
> >>> On 27.01.16 at 13:38, wrote:
> >> On January 27, 2016 at 7:24pm, wrote:
> >> >>> On 27.01.16 at 12:09, wrote:
> >> >> On January 27, 2016 at 6:48am, wrote:
> >> >> > From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> > Sent: Tuesday, January 26
>>> On 27.01.16 at 13:38, wrote:
>> On January 27, 2016 at 7:24pm, wrote:
>> >>> On 27.01.16 at 12:09, wrote:
>> >> On January 27, 2016 at 6:48am, wrote:
>> >> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> > Sent: Tuesday, January 26, 2016 11:53 PM
>> >
>> >
>> >> > Once again: Before
> On January 27, 2016 at 7:24pm, wrote:
> >>> On 27.01.16 at 12:09, wrote:
> >> On January 27, 2016 at 6:48am, wrote:
> >> > From: Jan Beulich [mailto:jbeul...@suse.com]
> >> > Sent: Tuesday, January 26, 2016 11:53 PM
> >
> >
> >> > Once again: Before getting started, please assess which route
>>> On 27.01.16 at 12:09, wrote:
>> On January 27, 2016 at 6:48am, wrote:
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: Tuesday, January 26, 2016 11:53 PM
>
>
>> > Once again: Before getting started, please assess which route is going
>> > to be the better one. Remember that we
> On January 27, 2016 at 6:48am, wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Tuesday, January 26, 2016 11:53 PM
> > Once again: Before getting started, please assess which route is going
> > to be the better one. Remember that we had already discussed and put
> > aside some
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 26, 2016 11:53 PM
>
> >> > At first, I am open for any solution.
> >> > pcidevs_lock is quite a big lock. For this point, it looks much better
> >> > to add a new flag to delay hiding device.
> >> > I am also afraid that it ma
>>> On 26.01.16 at 16:27, wrote:
>> On January 26, 2016 at 10:00pm, wrote:
>> >>> On 26.01.16 at 14:47, wrote:
>> > As you mentioned , I simply need to consult the bitmap along with the
>> > domain ID array.
>> >
>> > +If ( test_bit(did, iommu->domid_bitmap) && iommu->domid_map[did] >= 0 )
>> >
> On January 26, 2016 at 10:00pm, wrote:
> >>> On 26.01.16 at 14:47, wrote:
> > As you mentioned , I simply need to consult the bitmap along with the
> > domain ID array.
> >
> > +If ( test_bit(did, iommu->domid_bitmap) && iommu->domid_map[did] >= 0 )
> > + d = rcu_lock_domain_by_id(iommu->domi
>>> On 26.01.16 at 14:47, wrote:
> As you mentioned , I simply need to consult the bitmap along with the domain
> ID array.
>
> +If ( test_bit(did, iommu->domid_bitmap) && iommu->domid_map[did] >= 0 )
> + d = rcu_lock_domain_by_id(iommu->domid_map[did]);
>
> Is it right now?
Mostly, except t
> On January 25, 2016 at 10:09pm, wrote:
> >>> On 22.01.16 at 16:57, wrote:
> >> On January 22, 2016 at 12:31am, wrote:
> >> >>> On 21.01.16 at 17:16, wrote:
> >> >> On January 20, 2016 at 7:29 pm, wrote:
> >> >> >>> On 20.01.16 at 11:26, wrote:
> >> >> >> On January 15, 2016 at 9:10, wro
>>> On 22.01.16 at 16:57, wrote:
>> On January 22, 2016 at 12:31am, wrote:
>> >>> On 21.01.16 at 17:16, wrote:
>> >> On January 20, 2016 at 7:29 pm, wrote:
>> >> >>> On 20.01.16 at 11:26, wrote:
>> >> >> On January 15, 2016 at 9:10, wrote:
>> >> >> >>> On 23.12.15 at 09:25, wrote:
>> >> >
> On January 22, 2016 at 12:31am, wrote:
> >>> On 21.01.16 at 17:16, wrote:
> >> On January 20, 2016 at 7:29 pm, wrote:
> >> >>> On 20.01.16 at 11:26, wrote:
> >> >> On January 15, 2016 at 9:10, wrote:
> >> >> >>> On 23.12.15 at 09:25, wrote:
> >> >> > @@ -229,6 +239,63 @@ int qinval_device
>>> On 21.01.16 at 17:16, wrote:
>> On January 20, 2016 at 7:29 pm, wrote:
>> >>> On 20.01.16 at 11:26, wrote:
>> >> On January 15, 2016 at 9:10, wrote:
>> >> >>> On 23.12.15 at 09:25, wrote:
>> >> > @@ -229,6 +239,63 @@ int qinval_device_iotlb(struct iommu *iommu,
>> >> > return 0;
>>
> On January 20, 2016 at 7:29 pm, wrote:
> >>> On 20.01.16 at 11:26, wrote:
> >> On January 15, 2016 at 9:10, wrote:
> >> >>> On 23.12.15 at 09:25, wrote:
> >> > @@ -229,6 +239,63 @@ int qinval_device_iotlb(struct iommu *iommu,
> >> > return 0;
> >> > }
> >> >
> >> > +static void dev_inv
>>> On 20.01.16 at 11:26, wrote:
>> On January 15, 2016 at 9:10, wrote:
>> >>> On 23.12.15 at 09:25, wrote:
>> > @@ -229,6 +239,63 @@ int qinval_device_iotlb(struct iommu *iommu,
>> > return 0;
>> > }
>> >
>> > +static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
>> > +
Jan, thanks for your comments.
> On January 15, 2016 at 9:10, wrote:
> >>> On 23.12.15 at 09:25, wrote:
> > --- a/xen/drivers/passthrough/vtd/qinval.c
> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > @@ -190,9 +190,19 @@ static int queue_invalidate_wait(struct iommu
> > *iommu, static int inv
> On January 18, 2016 at 11:32pm, wrote:
> At 10:46 + 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 majori
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Monday, January 18, 2016 11:32 PM
>
> At 10:46 + 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
At 10:46 + 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 cha
>>> On 23.12.15 at 09:25, wrote:
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -190,9 +190,19 @@ static int queue_invalidate_wait(struct iommu *iommu,
> static int invalidate_sync(struct iommu *iommu)
> {
> struct qi_ctrl *qi_ctrl = iommu_qi_
E: [Xen-devel] [PATCH v4 3/3] VT-d: Fix vt-d Device-TLB flush
> timeout
> issue.
>
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Thursday, January 14, 2016 5:00 PM
> >
> > >>> On 14.01.16 at 02:22, wrote:
> > >> From: Jan Beulich
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, January 14, 2016 5:00 PM
>
> >>> On 14.01.16 at 02:22, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Wednesday, January 13, 2016 7:03 PM
> >>
> >> >> Jan,
> >> >> Patch 2/3 and Patch 3/3 are based on v3 (Actua
>>> On 14.01.16 at 02:22, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 13, 2016 7:03 PM
>>
>> >> 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_h
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 13, 2016 7:03 PM
>
> >> 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
> > flu
>>> On 13.01.16 at 07:12, wrote:
>> From: Xu, Quan
>> Sent: Thursday, January 07, 2016 9:47 PM
>>
>> > On January 07, 2016 9:28 PM, wrote:
>> > >>> On 07.01.16 at 02:39, wrote:
>> > > On January 06, 2016 7:26 PM, wrote:
>> > >> > I didn't think about the full logic thoroughly now. But it woul
> From: Xu, Quan
> Sent: Thursday, January 07, 2016 9:47 PM
>
> > On January 07, 2016 9:28 PM, wrote:
> > >>> On 07.01.16 at 02:39, wrote:
> > > On January 06, 2016 7:26 PM, wrote:
> > >> > I didn't think about the full logic thoroughly now. But it would
> > >> > always be good to not hide devi
On January 07, 2016 9:47 PM, wrote:
> 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 m
> On January 07, 2016 9:28 PM, wrote:
> >>> On 07.01.16 at 02:39, wrote:
> > On January 06, 2016 7:26 PM, 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
On January 06, 2016 7:26 PM, wrote:
> > > diff --git a/xen/drivers/passthrough/vtd/qinval.c
> > > b/xen/drivers/passthrough/vtd/qinval.c
> > > index b227e4e..7330c5d 100644
> > > --- a/xen/drivers/passthrough/vtd/qinval.c
> > > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > > @@ -190,9 +190,19 @@
> On December 25 2015, 11:06 AM, wrote:
> > From: Xu, Quan
> > Sent: Wednesday, December 23, 2015 4:26 PM
> >
> > Now if IOTLB/Context/IETC flush is timeout, panic hypervisor.
> > The coming patch set will fix it.
>
> again, please adjust comment to reflect what this patch is doing, i.e. only
>
> From: Xu, Quan
> Sent: Wednesday, December 23, 2015 4:26 PM
>
> Now if IOTLB/Context/IETC flush is timeout, panic hypervisor.
> The coming patch set will fix it.
again, please adjust comment to reflect what this patch is
doing, i.e. only about improvement on Device-TLB flush.
>
> If Device-TL
Now if IOTLB/Context/IETC flush is timeout, panic hypervisor.
The coming patch set will fix it.
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.
The hided Device will be
34 matches
Mail list logo
