On April 28, 2016 11:12 PM, Jan Beulich wrote:
> >>> On 28.04.16 at 17:03, wrote:
> > On April 28, 2016 10:36 PM, Jan Beulich wrote:
> >> >>> On 28.04.16 at 16:14, wrote:
> >> > On April 25, 2016 7:53 PM, Jan Beulich wrote:
> >> >> >>> On 18.04.16 at 16:00, wrote:
> >> >> > --- a/xen/drivers/
On April 28, 2016 10:36 PM, Jan Beulich wrote:
> >>> On 28.04.16 at 16:14, wrote:
> > On April 25, 2016 7:53 PM, Jan Beulich wrote:
> >> >>> On 18.04.16 at 16:00, wrote:
> >> > --- a/xen/drivers/passthrough/vtd/iommu.c
> >> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> >
> >
> >> > -static void
On April 25, 2016 7:53 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > -static void iommu_flush_all(void)
> > +static int iommu_flush_all(void)
>
> __must_check
>
The iommu_flush_all() i
On April 27, 2016 11:03 PM, Jan Beulich wrote:
> >>> On 27.04.16 at 16:26, wrote:
> > On April 25, 2016 5:27 PM, Jan Beulich wrote:
> >> >>> On 18.04.16 at 16:00, wrote:
> I.e. I continue to think that
>
> if ( is_hardware_domain() )
> printk();
> else
> domain_crash();
On April 27, 2016 11:48 PM, George Dunlap wrote:
> On 18/04/16 15:00, Quan Xu wrote:
> > If IOMMU mapping and unmapping failed, the domain (with the exception
> > of the hardware domain) is crashed, treated as a fatal error. Rollback
> > can be lighter weight.
> >
> > For the hardware domain, we d
On April 25, 2016 5:27 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -243,21 +243,33 @@ int iommu_map_page(struct domain *d,
> unsigned long gfn, unsigned long mfn,
> > unsig
On April 27, 2016 5:37 PM, Jan Beulich wrote:
> >>> On 27.04.16 at 10:49, wrote:
> > On April 25, 2016 5:51 PM, Jan Beulich wrote:
> >> >>> On 18.04.16 at 16:00, wrote:
> >> > --- a/xen/arch/x86/mm.c
> >> > +++ b/xen/arch/x86/mm.c
> >> > @@ -2467,7 +2467,7 @@ static int __get_page_type(struct p
On April 27, 2016 2:32 PM, Jan Beulich wrote:
> >>> On 27.04.16 at 08:21, wrote:
> > On April 26, 2016 8:49 PM, Jan Beulich wrote:
> >> Hmm, the "positive" here has nothing to do with the "positive" in patch 1.
> >> Please just have a look at xenmem_add_to_physmap() as a whole.
> >>
> >
> > Than
On April 25, 2016 5:51 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info
> *page, unsigned long type,
> > int preemptible) {
> >
On April 26, 2016 8:49 PM, Jan Beulich wrote:
> >>> On 26.04.16 at 14:23, wrote:
> > On April 25, 2016 6:19 PM, Jan Beulich wrote:
> >> >>> On 18.04.16 at 16:00, wrote:
> >> > --- a/xen/common/memory.c
> >> > +++ b/xen/common/memory.c
> >> > @@ -678,8 +678,9 @@ static int xenmem_add_to_physmap
On April 26, 2016 8:52 PM, Jan Beulich wrote:
> >>> On 26.04.16 at 13:50, wrote:
> > On April 25, 2016 7:40 PM, Jan Beulich wrote:
> >> >>> On 18.04.16 at 16:00, wrote:
> >> > While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> >> > However the existing panic() is going to b
On April 25, 2016 6:19 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -678,8 +678,9 @@ static int xenmem_add_to_physmap(struct domain
> *d,
> > if ( need_iommu(d) )
> > {
> > this_cpu(iommu_dont_flus
On April 25, 2016 7:40 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
> > While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> > However the existing panic() is going to be eliminated, so we must
> > propagate the IOMMU Device-TLB flush error up to the
> > iommu_iotl
On April 25, 2016 7:53 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
> > --- a/xen/arch/x86/acpi/power.c
> > +++ b/xen/arch/x86/acpi/power.c
> > @@ -45,19 +45,31 @@ void do_suspend_lowlevel(void);
> >
> > static int device_power_down(void)
> > {
> > +int err;
> > +
> > cons
On April 26, 2016 6:53 PM, Jan Beulich wrote:
> >>> On 26.04.16 at 12:15, wrote:
> > On April 26, 2016 5:11 PM, Jan Beulich wrote:
> >> >>> On 26.04.16 at 04:18, wrote:
> >> > On April 25, 2016 5:22 PM, Jan Beulich wrote:
> >> >> >>> On 18.04.16 at 16:00, wrote:
> >> >> > --- a/xen/drivers/pa
On April 25, 2016 8:00 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
> > --- a/xen/drivers/passthrough/vtd/extern.h
> > +++ b/xen/drivers/passthrough/vtd/extern.h
> > @@ -91,7 +91,7 @@ int is_igd_vt_enabled_quirk(void); void
> > platform_quirks_init(void); void vtd_ops_preamble_quir
On April 26, 2016 6:25 PM, Wei Liu wrote:
> For avoidance of doubt, this is purely status update, no action is needed on
> my part.
Yes.
> Let me know if I misunderstood.
>
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org
On April 26, 2016 5:11 PM, Jan Beulich wrote:
> >>> On 26.04.16 at 04:18, wrote:
> > On April 25, 2016 5:22 PM, Jan Beulich wrote:
> >> >>> On 18.04.16 at 16:00, wrote:
> >> > --- a/xen/drivers/passthrough/vtd/iommu.c
> >> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> >> > @@ -558,14 +558,16 @@
On April 26, 2016 1:41 PM, Emil Condrea wrote:
>Hi Quan,
>
>How are you ? I want to help you to get upstream the vtpm patches. I followed
>the emails on xen-devel and I see that the last status was at v8 series
>where Stefano asked to do some refactoring and splitting the patches into
>refactori
On April 25, 2016 6:07 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -617,11 +617,12 @@ static void intel_iommu_iotlb_flush_all(struct
> > domain
> > *d)
> > }
> >
> > /* clear one pag
On April 25, 2016 5:56 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
> > --- a/xen/common/grant_table.c
> > +++ b/xen/common/grant_table.c
> > @@ -1366,8 +1366,9 @@ gnttab_unmap_grant_ref(
> >
> > return 0;
> >
> > -fault:
> > -gnttab_flush_tlb(current->domain);
> > + fault:
On April 25, 2016 5:22 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -558,14 +558,16 @@ static void iommu_flush_all(void)
> > }
> > }
> >
> > -static void __intel_iommu_iotlb_flush
On April 25, 2016 5:22 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
>
> I thought we had agreed on best effort flushing when an error occurs. That
> means you shouldn't break out of the loop here, but accumulate errors.
> (Breaking out of the loop would be okay if it was conditional
On April 25, 2016 9:58pm, wrote:
> On 25/04/16 12:52, Jan Beulich wrote:
> On 18.04.16 at 16:00, wrote:
> >> --- a/xen/drivers/passthrough/arm/smmu.c
> >> +++ b/xen/drivers/passthrough/arm/smmu.c
> >> @@ -2540,7 +2540,7 @@ static int force_stage = 2;
> >>*/
> >> static u32 platform_fea
On April 25, 2016 4:41pm, Li, Liang Z wrote:
> > >> >>> On 30.03.16 at 09:28, wrote:
> > >> > 2016-03-29 18:39 GMT+08:00 Jan Beulich :
> > >> >> ---
> > >> >> I assume this also addresses the issue which
> > >> >>
> > >> http://lists.xenproject.org/archives/html/xen-devel/2016-
> 01/msg03189.
> >
On April 20, 2016 2:12pm, wrote:
> >>> "Xu, Quan" 04/20/16 7:29 AM >>>
> Ideally not, if it's a batch that it failing, The question just is whether at
> the point
> you issue the error message you can know another got already emitted. In no
>
On April 19, 2016 2:44pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > If IOMMU mapping and unmapping failed, the domain (with the exception
> > of the hardware domain) is crashed, treated as a fatal error. Rollback
> &
On April 19, 2016 2:46pm, Tian, Kevin wrote:
> > From: Quan Xu
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > While grant table is unmapping, the domain (with the exception of the
>
> unmapping -> unmapped.
>
A slightly different take, IMO the hypercall is not returned, so it is DOING.
> >
On April 19, 2016 2:58pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> > However the existing panic() is going to be eliminated, so we must
> >
On April 19, 2016 2:33pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > The propagation value from IOMMU flush interfaces may be positive,
> > which indicates callers need to flush cache, not one of faliures.
> >
> &
On April 19, 2016 2:51pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> > However the existing panic() is going to be eliminated, so we must
> >
On April 19, 2016 2:37pm, Tian, Kevin wrote:
> > From: Quan Xu
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > Now IOMMU mapping and unmapping failures are treated as a fatal to the
> > domain (with the exception of the hardware domain).
>
> 'Now' is more about eixsting state, while it's actual
On April 15, 2016 10:03pm, wrote:
> On 31/03/16 10:06, Xu, Quan wrote:
> > All,
> >
> > Here is a summary of my investigation of the abstract model:
> >
> > Below policies are adopted when deciding whether to rollback a callchain:
> >
> > 1. Domain
George,
In this discussion, most of them are memory-related problems. Your comments are
valuable.
If you have read this thread, could you give me some feedback? I really
appreciate your precious advice.
Quan
On March 31, 2016 5:06pm, Quan, Xu wrote:
> All,
>
> Here is a summary of my invest
On April 12, 2016 12:35am, Jan Beulich wrote:
> >>> On 11.04.16 at 05:27, wrote:
> > On April 11, 2016 11:10am, wrote:
> >> On March 29, 2016 3:37pm, Jan Beulich wrote:
> >> > >>> On 25.03.16 at 10:27, wrote:
> >> > > On March 18, 2016 6:20pm, wrote:
> >> > >> >>> On 17.03.16 at 07:54, wrote
On April 11, 2016 3:25pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Friday, April 08, 2016 10:21 AM
> >
> > On April 07, 2016 11:29pm, Jan Beulich wrote:
> > > >>> On 07.04.16 at 09:44, wrote:
> > > > On April 05, 2016 5:35pm, Jan Beu
On April 11, 2016 2:53pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Thursday, April 07, 2016 3:45 PM
> >
> > On April 05, 2016 5:35pm, Jan Beulich wrote:
> > > >>> On 01.04.16 at 16:47, wrote:
> > > > The dev_invalidate_iotlb() scans
On April 11, 2016 11:10am, wrote:
> On March 29, 2016 3:37pm, Jan Beulich wrote:
> > >>> On 25.03.16 at 10:27, wrote:
> > > On March 18, 2016 6:20pm, wrote:
> > >> >>> On 17.03.16 at 07:54, wrote:
> > >> > --- a/xen/drivers/passthrough/iommu.c
> > >> > +++ b/xen/drivers/passthrough/iommu.c
> >
On March 29, 2016 3:37pm, Jan Beulich wrote:
> >>> On 25.03.16 at 10:27, wrote:
> > On March 18, 2016 6:20pm, wrote:
> >> >>> On 17.03.16 at 07:54, wrote:
> >> > --- a/xen/drivers/passthrough/iommu.c
> >> > +++ b/xen/drivers/passthrough/iommu.c
> >> > @@ -554,11 +555,24 @@ static void iommu_flu
On April 05, 2016 5:48pm, Jan Beulich wrote:
> >>> On 01.04.16 at 16:47, wrote:
> > +static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
> > + u16 seg, u8 bus, u8 devfn)
> {
> > +struct domain *d = NULL;
> > +struct pci_dev *pdev;
On April 08, 2016 6:44am, wrote:
> >>> On 06.04.16 at 09:38, wrote:
> > On April 01, 2016 7:57pm, wrote:
> >> >>> On 31.03.16 at 11:06, wrote:
> >> > 4. __gnttab_unmap_common():rollback (no change)
> >> >
> >> > (Existing code)
> >> >>>...
> >> > if ( !kind )
> >> >
On April 07, 2016 11:29pm, Jan Beulich wrote:
> >>> On 07.04.16 at 09:44, wrote:
> > On April 05, 2016 5:35pm, Jan Beulich wrote:
> >> >>> On 01.04.16 at 16:47, wrote:
> >> > +{
> >> > +queue_invalidate_context(iommu, did, source_id,
> >> > + function_mask, granu
On April 05, 2016 5:35pm, Jan Beulich wrote:
> >>> On 01.04.16 at 16:47, wrote:
> > The dev_invalidate_iotlb() scans ats_devices list to flush ATS
> > devices, and the invalidate_sync() is put after dev_invalidate_iotlb()
> > to synchronize with hardware for flush status. If we assign multiple
>
On April 05, 2016 5:09pm, wrote:
> >>> On 01.04.16 at 16:47, wrote:
>
> The subject should mention "timeout", perhaps either in addition to or in
> place
> of "command line".
>
I prefer "VT-d: add a timeout parameter for Queued Invalidation".
> > --- a/docs/misc/xen-command-line.markdown
> >
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Wei
> Liu
> Sent: Friday, April 01, 2016 6:03 PM
> To: Xu, Quan
> Cc: Xen-devel; Daniel De Graaf; Wei Liu
> Subject: Re: [Xen-devel] [PATCH RFC v1 09/14] Makefile: delete
On April 01, 2016 7:57pm, wrote:
> >>> On 31.03.16 at 11:06, wrote:
> > 4. __gnttab_unmap_common():rollback (no change)
> >
> > (Existing code)
> >>>...
> > if ( !kind )
> > err = iommu_unmap_page(ld, op->frame);
> > else if ( !(kind & MAPKIND_WRITE) )
> >
On March 28, 2016 9:32pm, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 28, 2016 at 06:27:21AM +0000, Xu, Quan wrote:
> > On March 26, 2016 4:07am, Konrad Rzeszutek Wilk
> wrote:
> > > On Thu, Mar 24, 2016 at 01:57:58PM +0800, Quan Xu wrote:
>
>
DX
> I would r
On March 24, 2016 7:11pm, wrote:
> On March 24, 2016 6:33pm, Jan Beulich wrote:
> > >>> On 24.03.16 at 06:57, wrote:
> > without the other one even known to be almost ready to go in. I think
> > loose dependencies are okay, but in the case here everything would
> > better be presented together
On March 31, 2016 9:50pm, Wei Liu wrote:
> On Thu, Mar 31, 2016 at 10:21:22AM +0000, Xu, Quan wrote:
> > On March 11, 2016 12:53am, Wei Liu wrote:
> > > -build: $(STUBDOMPATH)
> > > +build: $(STUBDOM_BUILD)
> >
> > Wei,
> > in original code, in stubdo
On March 11, 2016 12:53am, Wei Liu wrote:
> -build: $(STUBDOMPATH)
> +build: $(STUBDOM_BUILD)
Wei,
in original code, in stubdom/vtpm and stubdom/vtpmmgr, the code style is
inconsistent and ugly.
Do you have any plan to fix them? :)
btw, if the others(or me) want to fix the code style, how to fi
+to 2 key maintainers,
On March 31, 2016 5:06pm, Xu, Quan wrote:
> All,
>
> Here is a summary of my investigation of the abstract model:
>
> Below policies are adopted when deciding whether to rollback a callchain:
>
> 1. Domain will be crashed immediately withi
All,
Here is a summary of my investigation of the abstract model:
Below policies are adopted when deciding whether to rollback a callchain:
1. Domain will be crashed immediately within iommu_{,un}map_page, treated as a
fatal error (with the exception of the hardware one). Whether to rollback
d
On March 30, 2016 10:28am, Xu, Quan wrote:
> If this is still the correct one, could you help me send out the correct one?
>
Sorry, a typo:
If this is still _not_ the correct one, could you help me send out the correct
one?
Quan
___
Xen-devel m
On March 29, 2016 3:21pm, wrote:
> >>> On 28.03.16 at 05:33, wrote:
> > On March 18, 2016 1:15am, wrote:
> >> >>> On 17.03.16 at 07:54, wrote:
> >> > --- a/xen/common/grant_table.c
> >> > +++ b/xen/common/grant_table.c
> >> > @@ -932,8 +932,9 @@ __gnttab_map_grant_ref(
> >> > {
> >
On March 29, 2016 10:21pm, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 29, 2016 at 01:32:02AM +0000, Xu, Quan wrote:
> > On March 28, 2016 10:11pm, Konrad Rzeszutek Wilk
> wrote:
> > > >
> > > > > > +list_del(&pdev->domain_li
On March 28, 2016 10:11pm, Konrad Rzeszutek Wilk wrote:
> >
> > > > +list_del(&pdev->domain_list);
> > > > +pdev->domain = NULL;
> > > > +pci_hide_existing_device(pdev);
> > > > +break;
> > > > +}
> > > > +}
> > > > +
> > > > +pcidevs
+cc Konrad Rzeszutek Wilk , who is also reviewing this
patch.
On March 24, 2016 11:38pm, Dario Faggioli wrote:
> On Thu, 2016-03-24 at 13:57 +0800, Quan Xu wrote:
> > If Device-TLB flush timed out, we would hide the target ATS device and
> > crash the domain owning this ATS device. If impacted d
On March 26, 2016 4:07am, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 24, 2016 at 01:57:58PM +0800, Quan Xu wrote:
>
> Hey!
>
> Thanks for the patch!
>
> I see that you have __must_check..
>
> But if you check the callchain:
>
> iommu_flush_iec_[index|global] ->
> __iommu_flush_iec->invali
On March 26, 2016 4:32am, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 24, 2016 at 01:57:59PM +0800, Quan Xu wrote:
> > If Device-TLB flush timed out, we would hide the target ATS device and
> > crash the domain owning this ATS device. If impacted domain is
> > hardware domain, just throw out a warn
On March 26, 2016 4:40am, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 24, 2016 at 04:38:05PM +0100, Dario Faggioli wrote:
> > On Thu, 2016-03-24 at 13:57 +0800, Quan Xu wrote:
> > > If Device-TLB flush timed out, we would hide the target ATS device
> > > and crash the domain owning this ATS device.
On March 18, 2016 1:15am, wrote:
> >>> On 17.03.16 at 07:54, wrote:
> > @@ -53,11 +55,21 @@ static int device_power_down(void)
> >
> > ioapic_suspend();
> >
> > -iommu_suspend();
> > +err = iommu_suspend();
> > +if ( err )
> > +goto iommu_suspend_error;
> >
> > lapic
On March 24, 2016 7:31pm, wrote:
> Recursive locks know their current owner, and since we use the function solely
> to determine whether a particular lock is being held by the current CPU (which
> so far has been an imprecise check), make actually check the owner for
> recusrively acquired locks.
On March 18, 2016 6:20pm, wrote:
> >>> On 17.03.16 at 07:54, wrote:
> > --- a/xen/drivers/passthrough/amd/iommu_init.c
> > +++ b/xen/drivers/passthrough/amd/iommu_init.c
> > @@ -1339,12 +1339,14 @@ static void invalidate_all_devices(void)
> > iterate_ivrs_mappings(_invalidate_all_devices);
>
On March 24, 2016 11:38pm, wrote:
> On Thu, 2016-03-24 at 13:57 +0800, Quan Xu wrote:
> > If Device-TLB flush timed out, we would 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 hidden devi
On March 24, 2016 11:06pm, wrote:
> On Thu, 2016-03-24 at 14:56 +0100, Dario Faggioli wrote:
> > On Thu, 2016-03-24 at 13:57 +0800, Quan Xu wrote:
> > >
> > > @@ -134,8 +133,8 @@ int dev_invalidate_iotlb(struct iommu *iommu,
> > > u16
> > > did,
> > > /* invalidate all translations:
>
On March 24, 2016 5:59pm, wrote:
> >>> On 24.03.16 at 10:02, wrote:
> > On March 18, 2016 5:49pm, wrote:
> >3. For iommu_{,un}map_page(), we'd better fix it as a normal error,
> > as the error is not only from iommu flush, .e.g, '-ENOMEM'.
> > So, we need to {,un}map from the IOMMU, r
On March 24, 2016 7:04pm, wrote:
> On Thu, 2016-03-24 at 13:57 +0800, Quan Xu wrote:
> >
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -1532,6 +1532,13 @@ Note that if **watchdog** option is also
> > specified vpmu will be turned off.
> > As th
On March 24, 2016 6:33pm, Jan Beulich wrote:
> >>> On 24.03.16 at 06:57, wrote:
> > **NOTE**
> >This patch set should base on 2 prereq patch sets:
> > a). Make the pcidevs_lock a recursive one.
>
> This one already went in, so is pointless to mention here.
Agreed,
>
> > b). Check
On March 18, 2016 5:49pm, wrote:
> >>> On 18.03.16 at 10:38, wrote:
> > On Fri, 2016-03-18 at 03:29 -0600, Jan Beulich wrote:
> >> >
> >> Not sure what exactly you're asking for: As said, we first need to
> >> settle on an abstract model. Do we want IOMMU mapping failures to be
> >> fatal to the
On March 18, 2016 4:10pm, wrote:
> >>> On 18.03.16 at 04:19, wrote:
> > On March 17, 2016 8:34pm, George Dunlap
> wrote:
> >> On Thu, Mar 17, 2016 at 12:30 PM, George Dunlap
> >> wrote:
> >> > On Thu, Mar 17, 2016 at 6:54 AM, Quan Xu wrote:
> >> >> --- a/xen/arch/x86/mm/p2m-ept.c
> >> >> +++ b
On March 23, 2016 1:37pm, wrote:
> > From: Xu, Quan
> > Sent: Wednesday, March 23, 2016 11:30 AM
> >
> > >
> > > Yes, still inconsistent. As I said, you put invalidation sync within
> > > dev_invalidate_iotlb, while for all other IOMMU invalidation
On March 21, 2016 11:27am, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Friday, March 18, 2016 8:22 PM
> > > > static void queue_invalidate_iec(struct iommu *iommu, u8 granu,
> > > > u8 im, u16 iidx) {
> > > > unsigned long flags;
>
(( __ sorry, I was out of office on Mon./Tues. __))
On March 21, 2016 11:27am, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Friday, March 18, 2016 8:22 PM
> > > > static void queue_invalidate_iec(struct iommu *iommu, u8 granu,
> > > > u8 im, u16 iidx)
On March 17, 2016 8:30pm, wrote:
> On Thu, Mar 17, 2016 at 6:54 AM, Quan Xu wrote:
> > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index
> > c997b53..526548e 100644
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info
On March 17, 2016 4:14pm, wrote:
> >>> On 17.03.16 at 09:11, wrote:
> > On March 17, 2016 3:45pm, Tian, Kevin wrote:
> >> > From: Xu, Quan
> >> > Sent: Thursday, March 17, 2016 3:13 PM diff --git
> >> > a/xen/drivers/passthrough/vtd/
On March 18, 2016 4:20pm, wrote:
> >>> On 18.03.16 at 08:54, wrote:
> > On March 17, 2016 8:30pm, wrote:
> >> On Thu, Mar 17, 2016 at 6:54 AM, Quan Xu wrote:
> >> > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index
> >> > c997b53..526548e 100644
> >> > --- a/xen/arch/x86/mm.c
> >> > +++
On March 16, 2016 6:45pm, wrote:
> >>> On 16.03.16 at 09:39, wrote:
> > On Wed, 2016-03-16 at 02:39 +, Xu, Quan wrote:
> Quan - before sending such pings, please be sure to actually check the staging
> branch. And generally Dario is right - if anything, you should h
On March 17, 2016 8:34pm, George Dunlap wrote:
> On Thu, Mar 17, 2016 at 12:30 PM, George Dunlap
> wrote:
> > On Thu, Mar 17, 2016 at 6:54 AM, Quan Xu wrote:
> >> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index
> >> c997b53..526548e 100644
> >> --- a/xen/arch/x86/mm.c
> >> +++ b/xen/arc
On March 17, 2016 4:17pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Thursday, March 17, 2016 3:13 PM diff --git
> > a/xen/drivers/passthrough/vtd/qinval.c
> > b/xen/drivers/passthrough/vtd/qinval.c
> > index 37a15fb..2a5c638 100644
> > --- a/xen/driver
On March 17, 2016 3:38pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Thursday, March 17, 2016 2:55 PM
> >
> > Current code would be panic(), when VT-d Device-TLB flush timed out.
> > the panic() is going to be eliminated, so we must check all kinds of
> &g
On March 17, 2016 7:14pm, Tian, Kevin wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Thursday, March 17, 2016 5:43 PM
> >
> > >>> On 17.03.16 at 09:17, wrote:
> > >> From: Xu, Quan
> > >> Sent: Thursday, March 17, 2016
On March 17, 2016 11:31pm, wrote:
> On Thu, Mar 17, 2016 at 6:54 AM, Quan Xu wrote:
> > Current code would be panic(), when VT-d Device-TLB flush timed out.
> > the panic() is going to be eliminated, so we must check all kinds of
> > error and all the way up the call trees.
> >
> > Signed-off-by:
On March 17, 2016 9:37pm, Haozhong Zhang wrote:
> For PV guests (if we add vNVDIMM support for them in future), as I'm going to
> use page_info struct for it, I suppose the current mechanism in Xen can handle
> this case. I'm not familiar with PV memory management
The below web may be helpful:
h
On March 18, 2016 7:19pm, wrote:
> >>> On 17.03.16 at 08:12, wrote:
> > --- a/xen/drivers/passthrough/vtd/qinval.c
> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > @@ -233,6 +233,57 @@ int qinval_device_iotlb(struct iommu *iommu,
> > return 0;
> > }
> >
> > +static void dev_invalidate_iot
On March 17, 2016 3:45pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Thursday, March 17, 2016 3:13 PM diff --git
> > a/xen/drivers/passthrough/vtd/qinval.c
> > b/xen/drivers/passthrough/vtd/qinval.c
> > index b81b0bd..37a15fb 100644
> > --- a/xen/driver
Hi,
__iiuc__, this patch set is ready for staging branch. if yes, could you help
me merge it into staging branch?
Then, I would send out remaining patch sets on it. otherwise, there are some
conflicts to it. Thanks.
Quan
On March 10, 2016 10:10pm, wrote:
> This patch set makes the pcidevs_l
On March 15, 2016 12:38pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, March 14, 2016 3:16 PM
> >
> > We confirmed with VT-d hardware team that 1ms is large enough for
> > IOMMU internal flush. So We can change the DMAR_OPERATION_TIMEOUT
> from
> &
On March 10, 2016 11:56pm, Wei Liu wrote:
> On Thu, Mar 10, 2016 at 10:08:04AM -0500, Meng Xu wrote:
> > On Thu, Mar 10, 2016 at 9:42 AM, Dario Faggioli
> > wrote:
> > > Meng Xu is one of the maintainers of the RT-Xen project, which is
> > > from where the RTDS scheduler comes. He also is the main
On March 11, 2016 6:36pm, wrote:
> On Fri, 2016-03-11 at 06:54 +0000, Xu, Quan wrote:
> > On March 11, 2016 11:25am, wrote:
> > >
> > > On Wed, Mar 9, 2016 at 8:17 AM, Quan Xu wrote:
> > > >
> > > > pcidevs_lock should be held with interrupt
On March 11, 2016 11:25am, wrote:
> On Wed, Mar 9, 2016 at 8:17 AM, Quan Xu wrote:
> > pcidevs_lock should be held with interrupt enabled. However there
> > remains an exception in AMD IOMMU code, where the lock is acquired
> > with interrupt disabled. This inconsistency might lead to deadlock.
>
On March 11, 2016 8:24am, wrote:
> > From: Xu, Quan
> > Sent: Thursday, March 10, 2016 10:10 PM
> >
> > pcidevs_lock doesn't require interrupts to be disabled while being acquired.
> > However there remains an exception in AMD IOMMU code, where the lock
>
On March 10, 2016 10:39pm, wrote:
> On Thu, 2016-03-10 at 07:32 -0700, Jan Beulich wrote:
> > > > > On 10.03.16 at 15:10, wrote:
> > > The pcidevs_lock is going to be recursively taken for hiding ATS
> > > device, when VT-d Device-TLB flush timed out.
> > >
> > > Signed-off-by: Quan Xu
> > > Ack
On March 10, 2016 10:32pm, wrote:
> >>> On 10.03.16 at 15:10, wrote:
> > The pcidevs_lock is going to be recursively taken for hiding ATS
> > device, when VT-d Device-TLB flush timed out.
> >
> > Signed-off-by: Quan Xu
> > Acked-by: Kevin Tian
>
> Acked-by: Jan Beulich
Jan, thanks!!
I would s
On March 10, 2016 5:53pm, wrote:
> >>> On 09.03.16 at 14:17, wrote:
> > Signed-off-by: Quan Xu
> > Acked-by: Kevin Tian
>
> The patch itself looks mostly fine now (see below for the minor left issues),
> but
> the complete lack of a description (which should state why this change is
> being
CC Kevin,
On March 09, 2016 11:00pm, wrote:
> On Wed, 2016-03-09 at 21:17 +0800, Quan Xu wrote:
> > pcidevs_lock should be held with interrupt enabled.
> >
> There's a message from Jan when he says:
> < disabled while being acquired".>>
>
> :-O
>
> > However there remains
> > an exception in A
On March 09, 2016 10:45pm, Dario Faggioli wrote:
> On Wed, 2016-03-09 at 06:55 -0700, Jan Beulich wrote:
> > >
> > > > > On 09.03.16 at 14:46, wrote:
> > > Now I am still not clear for this point- "this inconsistency might
> > > lead to deadlock".
> > > I think it is similar to 'mixing interrupt d
On March 09, 2016 9:56pm, wrote:
> >>> On 09.03.16 at 14:46, wrote:
> > Now I am still not clear for this point- "this inconsistency might
> > lead to deadlock".
> > I think it is similar to 'mixing interrupt disabled and enabled
> > spinlocks is something we disallow'.
> > I hope you can give me
On March 10, 2016 1:45am, wrote:
> On Wed, 2016-03-09 at 21:17 +0800, Quan Xu wrote:
> > Signed-off-by: Quan Xu
> > Acked-by: Kevin Tian
> >
> Reviewed-by: Dario Faggioli
>
> And I've applied and build tested it, against current staging, and this time,
> it
> worked. :-)
>
Dario, thanks!! :
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Wednesday, March 09, 2016 9:20 PM
> To: Xu, Quan
> Cc: Suravee Suthikulpanit; xen-devel@lists.xen.org; Jan Beulich; Tian, Kevin
> Subject: Re: [Xen-devel] [PATCH v2 1/2] IOMMU/spinloc
On March 09, 2016 6:25pm, wrote:
> On Wed, 2016-03-09 at 07:31 +0000, Xu, Quan wrote:
> > On March 09, 2016 1:19pm, wrote:
> > >
> > > > When iommu_setup() is called in __start_xen(), interrupts have
> > > > already been enabled, and nothing disables
201 - 300 of 529 matches
Mail list logo
