At 01:31 -0600 on 02 Oct (1443749497), Jan Beulich wrote:
> >>> George Dunlap 10/01/15 6:16 PM >>>
> >On 01/10/15 11:25, Jan Beulich wrote:
> >> TBD: As already mentioned on the large-page-MMIO-mapping patch, there
> >> is an apparent inconsistency with PoD handling: 2M mappings get
> >>
>>> On 02.10.15 at 11:47, wrote:
> On Fri, Oct 2, 2015 at 8:31 AM, Jan Beulich wrote:
> George Dunlap 10/01/15 6:16 PM >>>
>>>On 01/10/15 11:25, Jan Beulich wrote:
TBD: As already mentioned on the large-page-MMIO-mapping patch, there
is an apparent inconsistency with PoD handl
On Fri, Oct 2, 2015 at 8:31 AM, Jan Beulich wrote:
George Dunlap 10/01/15 6:16 PM >>>
>>On 01/10/15 11:25, Jan Beulich wrote:
>>> TBD: As already mentioned on the large-page-MMIO-mapping patch, there
>>> is an apparent inconsistency with PoD handling: 2M mappings get
>>> valid entr
On Fri, Oct 2, 2015 at 10:16 AM, Wei Liu wrote:
> On Fri, Oct 02, 2015 at 01:31:37AM -0600, Jan Beulich wrote:
>> >>> George Dunlap 10/01/15 6:16 PM >>>
>> >On 01/10/15 11:25, Jan Beulich wrote:
>> >> TBD: As already mentioned on the large-page-MMIO-mapping patch, there
>> >> is an apparent
>>> Wei Liu 10/02/15 11:16 AM >>>
>I think George and you are talking about another function? Is there
>anything that prevents this patch from being committed as-is?
Nothing technical. Just me getting into the office (early afternoon I guess).
Jan
_
On Fri, Oct 02, 2015 at 01:31:37AM -0600, Jan Beulich wrote:
> >>> George Dunlap 10/01/15 6:16 PM >>>
> >On 01/10/15 11:25, Jan Beulich wrote:
> >> TBD: As already mentioned on the large-page-MMIO-mapping patch, there
> >> is an apparent inconsistency with PoD handling: 2M mappings get
> >>
>>> George Dunlap 10/01/15 6:16 PM >>>
>On 01/10/15 11:25, Jan Beulich wrote:
>> TBD: As already mentioned on the large-page-MMIO-mapping patch, there
>> is an apparent inconsistency with PoD handling: 2M mappings get
>> valid entries created, while 4k mappings don't. It would seem to
>>
On 01/10/15 11:25, Jan Beulich wrote:
> Whether the MFN changes does not depend on the new entry being valid
> (but solely on the old one), and the need to update or TLB-flush also
> depends on permission changes.
>
> Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
> ---
> v2: Split from
On Thu, Oct 01, 2015 at 04:25:01AM -0600, Jan Beulich wrote:
> Whether the MFN changes does not depend on the new entry being valid
> (but solely on the old one), and the need to update or TLB-flush also
> depends on permission changes.
>
> Signed-off-by: Jan Beulich
Release-acked-by: Wei Liu
On 01/10/15 15:36, Jan Beulich wrote:
On 01.10.15 at 15:34, wrote:
>> On 01/10/15 11:25, Jan Beulich wrote:
>>> @@ -645,11 +665,12 @@ p2m_pt_set_entry(struct p2m_domain *p2m,
>>> && (gfn + (1UL << page_order) - 1 > p2m->max_mapped_pfn) )
>>> p2m->max_mapped_pfn = gfn + (1UL
>>> On 01.10.15 at 15:34, wrote:
> On 01/10/15 11:25, Jan Beulich wrote:
>> @@ -645,11 +665,12 @@ p2m_pt_set_entry(struct p2m_domain *p2m,
>> && (gfn + (1UL << page_order) - 1 > p2m->max_mapped_pfn) )
>> p2m->max_mapped_pfn = gfn + (1UL << page_order) - 1;
>>
>> -if ( iomm
On 01/10/15 11:25, Jan Beulich wrote:
> Whether the MFN changes does not depend on the new entry being valid
> (but solely on the old one), and the need to update or TLB-flush also
> depends on permission changes.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Split from larger patch. Fix logic determ
Whether the MFN changes does not depend on the new entry being valid
(but solely on the old one), and the need to update or TLB-flush also
depends on permission changes.
Signed-off-by: Jan Beulich
---
v2: Split from larger patch. Fix logic determining whether to update/
flush IOMMU mappings.
13 matches
Mail list logo
