Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

>>> On 26.02.16 at 12:48, wrote: > I would summarize as follows and make sure we are on the same page. > > 1) make pcidevs_lock only visible inside xen/drivers/passthrough/pci.c, >turning the definition of the variable into a static one, and getting rid > of its

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

On February 26, 2016 6:11pm, wrote: > >>> On 26.02.16 at 10:24, wrote: > > On February 26, 2016 4:15pm, wrote: > >> >>> On 26.02.16 at 08:37, wrote: > >> > On February 25, 2016 8:24pm, wrote: > >>

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

>>> On 26.02.16 at 11:08, wrote: >> On February 26, 2016 4:15pm, wrote: >> >>> On 26.02.16 at 08:37, wrote: >> > On February 25, 2016 8:24pm, wrote: >> >> >>> On 25.02.16 at 13:14, wrote: >> >> >

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

>>> On 26.02.16 at 10:24, wrote: > On February 26, 2016 4:15pm, wrote: >> >>> On 26.02.16 at 08:37, wrote: >> > On February 25, 2016 8:24pm, wrote: >> >> >>> On 25.02.16 at 13:14, wrote: >> >> > On

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

> On February 26, 2016 4:15pm, wrote: > >>> On 26.02.16 at 08:37, wrote: > > On February 25, 2016 8:24pm, wrote: > >> >>> On 25.02.16 at 13:14, wrote: > >> > On February 25, 2016 4:59pm, wrote: >

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

On February 26, 2016 4:15pm, wrote: > >>> On 26.02.16 at 08:37, wrote: > > On February 25, 2016 8:24pm, wrote: > >> >>> On 25.02.16 at 13:14, wrote: > >> > On February 25, 2016 4:59pm, wrote: > > >

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

>>> On 26.02.16 at 09:14, wrote: > Nevertheless I'd recommend not mixing things for the pcidevs > one, as its uses are scattered around too much for it to be > reasonably possible to prove correctness if done that way. > Instead please make the lock a static variable in e.g. >

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

>>> On 26.02.16 at 08:37, wrote: > On February 25, 2016 8:24pm, wrote: >> >>> On 25.02.16 at 13:14, wrote: >> > On February 25, 2016 4:59pm, wrote: > >> >> However, the same effect could be achieved by making the lock

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

On February 25, 2016 8:24pm, wrote: > >>> On 25.02.16 at 13:14, wrote: > > On February 25, 2016 4:59pm, wrote: > >> However, the same effect could be achieved by making the lock a > >> recursive one, which would then seem to more

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

> On February 25, 2016 8:24pm, wrote: > >>> On 25.02.16 at 13:14, wrote: > > On February 25, 2016 4:59pm, wrote: > >> I'd > >> really suggest investigating alternatives. One that comes to mind > >> would be to move acquiring/releasing

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

On Thu, 2016-02-25 at 05:23 -0700, Jan Beulich wrote: > > > > On 25.02.16 at 13:14, wrote: > >  > > To me, this might be fine. > > Does Per-CPU flag refer to this_cpu(iommu_dont_flush_iotlb) or > > variant? > > Yes. But I'd prefer ... > > > > However, the same effect could be

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

>>> On 25.02.16 at 13:14, wrote: > On February 25, 2016 4:59pm, wrote: >> I'd >> really suggest investigating alternatives. One that comes to mind would be to >> move acquiring/releasing pcidevs_lock into a helper function, and setting a >> per-CPU flag

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

+CC Dario who is also watching this patch set. On February 25, 2016 4:59pm, wrote: > >>> On 25.02.16 at 07:56, wrote: > >> On February 17, 2016 10:23pm, wrote: > >> >>> On 05.02.16 at 11:18, wrote: > >> > to pass down

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

>>> On 25.02.16 at 07:56, wrote: >> On February 17, 2016 10:23pm, wrote: >> >>> On 05.02.16 at 11:18, wrote: >> > to pass down a flag indicating whether the lock is being held, and >> > check the way up the call trees. >> >> Same

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

>>> On 05.02.16 at 11:18, wrote: > to pass down a flag indicating whether the lock is being held, > and check the way up the call trees. Same comments as on the previous patch; most of the changes outside of xen/drivers/passthrough/ seem to be avoidable here. Jan

[Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

to pass down a flag indicating whether the lock is being held, and check the way up the call trees. Signed-off-by: Quan Xu --- xen/arch/x86/mm.c | 9 ++--- xen/arch/x86/mm/p2m-ept.c | 7 --- xen/arch/x86/mm/p2m-pt.c