On Tue, 8 Oct 2019 at 09:25, Jan Beulich wrote:
>
> On 01.10.2019 17:11, Paul Durrant wrote:
> > --- a/xen/arch/x86/mm/paging.c
> > +++ b/xen/arch/x86/mm/paging.c
> > @@ -209,15 +209,15 @@ static int paging_free_log_dirty_bitmap(struct domain
> > *d, int rc)
> > return rc;
> > }
> >
> > -in
On 01.10.2019 17:11, Paul Durrant wrote:
> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -209,15 +209,15 @@ static int paging_free_log_dirty_bitmap(struct domain
> *d, int rc)
> return rc;
> }
>
> -int paging_log_dirty_enable(struct domain *d, bool_t log_global)
> +i
On 10/2/19 10:10 AM, Andrew Cooper wrote:
> On 02/10/2019 09:40, Jan Beulich wrote:
>> On 01.10.2019 17:11, Paul Durrant wrote:
>>> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
>>> domain, migration may be needlessly vetoed due to the check of
>>> is_iommu_enabled() in pa
On Wed, 2 Oct 2019 at 10:42, Jan Beulich wrote:
>
> On 02.10.2019 11:10, Andrew Cooper wrote:
> > On 02/10/2019 09:40, Jan Beulich wrote:
> >> On 01.10.2019 17:11, Paul Durrant wrote:
> >>> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
> >>> domain, migration may be needl
On 02.10.2019 11:10, Andrew Cooper wrote:
> On 02/10/2019 09:40, Jan Beulich wrote:
>> On 01.10.2019 17:11, Paul Durrant wrote:
>>> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
>>> domain, migration may be needlessly vetoed due to the check of
>>> is_iommu_enabled() in pa
On Wed, 2 Oct 2019 at 10:12, Andrew Cooper wrote:
>
> On 02/10/2019 09:40, Jan Beulich wrote:
> > On 01.10.2019 17:11, Paul Durrant wrote:
> >> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
> >> domain, migration may be needlessly vetoed due to the check of
> >> is_iommu_
On Wed, 2 Oct 2019 at 10:26, Jan Beulich wrote:
>
> On 02.10.2019 10:59, Paul Durrant wrote:
> > On Wed, 2 Oct 2019 at 09:42, Jan Beulich wrote:
> >>
> >> On 01.10.2019 17:11, Paul Durrant wrote:
> >>> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
> >>> domain, migration
On 02.10.2019 10:59, Paul Durrant wrote:
> On Wed, 2 Oct 2019 at 09:42, Jan Beulich wrote:
>>
>> On 01.10.2019 17:11, Paul Durrant wrote:
>>> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
>>> domain, migration may be needlessly vetoed due to the check of
>>> is_iommu_enab
On 02/10/2019 09:40, Jan Beulich wrote:
> On 01.10.2019 17:11, Paul Durrant wrote:
>> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
>> domain, migration may be needlessly vetoed due to the check of
>> is_iommu_enabled() in paging_log_dirty_enable().
>> There is actually no
On Wed, 2 Oct 2019 at 09:42, Jan Beulich wrote:
>
> On 01.10.2019 17:11, Paul Durrant wrote:
> > Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
> > domain, migration may be needlessly vetoed due to the check of
> > is_iommu_enabled() in paging_log_dirty_enable().
> > There
On 01.10.2019 17:11, Paul Durrant wrote:
> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
> domain, migration may be needlessly vetoed due to the check of
> is_iommu_enabled() in paging_log_dirty_enable().
> There is actually no need to prevent logdirty from being enabled u
Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
domain, migration may be needlessly vetoed due to the check of
is_iommu_enabled() in paging_log_dirty_enable().
There is actually no need to prevent logdirty from being enabled unless
devices are assigned to a domain and that d
12 matches
Mail list logo
