On Thu, 20 Jul 2017, Alexey G wrote:
> On Wed, 19 Jul 2017 11:00:26 -0700 (PDT)
> Stefano Stabellini wrote:
>
> > My expectation is that unlocked mappings are much more frequent than
> > locked mappings. Also, I expect that only very rarely we'll be able to
> > reuse
On Thu, 20 Jul 2017, Alexey G wrote:
> On Wed, 19 Jul 2017 11:00:26 -0700 (PDT)
> Stefano Stabellini wrote:
>
> > My expectation is that unlocked mappings are much more frequent than
> > locked mappings. Also, I expect that only very rarely we'll be able to
> > reuse
On Wed, 19 Jul 2017 11:00:26 -0700 (PDT)
Stefano Stabellini wrote:
> My expectation is that unlocked mappings are much more frequent than
> locked mappings. Also, I expect that only very rarely we'll be able to
> reuse locked mappings. Over the course of a VM lifetime, it
On Wed, 19 Jul 2017, Alexey G wrote:
> Stefano,
>
> On Tue, 18 Jul 2017 15:17:25 -0700 (PDT)
> Stefano Stabellini wrote:
>
> > > The patch modifies the behavior in which MapCacheEntry's are added to
> > > the list, avoiding duplicates.
> >
> > I take that the idea is
Stefano,
On Tue, 18 Jul 2017 15:17:25 -0700 (PDT)
Stefano Stabellini wrote:
> > The patch modifies the behavior in which MapCacheEntry's are added to
> > the list, avoiding duplicates.
>
> I take that the idea is to always go through the whole list to check for
>
On Tue, 11 Jul 2017, Alexey G wrote:
> Under certain circumstances normal xen-mapcache functioning may be broken
> by guest's actions. This may lead to either QEMU performing exit() due to
> a caught bad pointer (and with QEMU process gone the guest domain simply
> appears hung afterwards) or
Under certain circumstances normal xen-mapcache functioning may be broken
by guest's actions. This may lead to either QEMU performing exit() due to
a caught bad pointer (and with QEMU process gone the guest domain simply
appears hung afterwards) or actual use of the incorrect pointer inside
QEMU