Tim Deegan
2009-Nov-16 17:00 UTC
[Xen-devel] [PATCH] Relax assertion in VRAM tracking code
The original assertion is too strict, as it includes the A/D bits of the PTE, which (by design) can change under our feet. Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2009-Nov-23 11:26 UTC
Re: [Xen-devel] [PATCH] Relax assertion in VRAM tracking code
>>> Tim Deegan <Tim.Deegan@citrix.com> 16.11.09 18:00 >>> >The original assertion is too strict, as it includes the A/D bits of the >PTE, which (by design) can change under our feet. > >Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>Wouldn''t the comparison a few lines down from the ASSERT() thus fixed also benefit from a similar adjustment? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2009-Nov-23 11:39 UTC
Re: [Xen-devel] [PATCH] Relax assertion in VRAM tracking code
At 11:26 +0000 on 23 Nov (1258975601), Jan Beulich wrote:> >>> Tim Deegan <Tim.Deegan@citrix.com> 16.11.09 18:00 >>> > >The original assertion is too strict, as it includes the A/D bits of the > >PTE, which (by design) can change under our feet. > > > >Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com> > > Wouldn''t the comparison a few lines down from the ASSERT() thus fixed > also benefit from a similar adjustment?Actually, on closer inspection my original fix was wrong; the bottom 12 bits of sl1ma are taken from the _pointer_ to the sl1e, not the contents, so the assertion is plausible. Keir, can you please revert it? Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel