From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Qemu-devel] [PATCH] xen-mapcache: don't unmap locked entry during mapcache invalidation
Date: Thu, 15 Mar 2012 18:10:57 +0100 [thread overview]
Message-ID: <20120315171056.GA20701@aepfle.de> (raw)
In-Reply-To: <alpine.DEB.2.00.1203151713280.923@kaball-desktop>
On Thu, Mar 15, Stefano Stabellini wrote:
> On Thu, 15 Mar 2012, Julien Grall wrote:
> > When an IOREQ_TYPE_INVALIDATE is sent to QEMU, it invalidates all entry
> > of the map cache even if it's locked.
> >
> > QEMU is not able to know that entry was invalidated, so when an IO
> > access is requested a segfault occured.
>
> The problem here is the long term mappings in QEMU that cannot easily be
> re-created.
> I am not sure whether this can cause any trouble to things like
> xenpaging.
Yes, I was wondering about this as well. If the request is made, then
its expected that all mappings disappear because they can point to
ballooned gfns. IF that case is safe, then all is fine.
In case of xenpaging its not an issue because xenpaging just asks qemu
to release mappings so that the usage count of mfns drops to 1, so that
they can be nominated for eviction. If that fails, not a big deal as it
just means that no more pages can be evicted. xenpaging will retry.
Olaf
WARNING: multiple messages have this Message-ID (diff)
From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [PATCH] xen-mapcache: don't unmap locked entry during mapcache invalidation
Date: Thu, 15 Mar 2012 18:10:57 +0100 [thread overview]
Message-ID: <20120315171056.GA20701@aepfle.de> (raw)
In-Reply-To: <alpine.DEB.2.00.1203151713280.923@kaball-desktop>
On Thu, Mar 15, Stefano Stabellini wrote:
> On Thu, 15 Mar 2012, Julien Grall wrote:
> > When an IOREQ_TYPE_INVALIDATE is sent to QEMU, it invalidates all entry
> > of the map cache even if it's locked.
> >
> > QEMU is not able to know that entry was invalidated, so when an IO
> > access is requested a segfault occured.
>
> The problem here is the long term mappings in QEMU that cannot easily be
> re-created.
> I am not sure whether this can cause any trouble to things like
> xenpaging.
Yes, I was wondering about this as well. If the request is made, then
its expected that all mappings disappear because they can point to
ballooned gfns. IF that case is safe, then all is fine.
In case of xenpaging its not an issue because xenpaging just asks qemu
to release mappings so that the usage count of mfns drops to 1, so that
they can be nominated for eviction. If that fails, not a big deal as it
just means that no more pages can be evicted. xenpaging will retry.
Olaf
next prev parent reply other threads:[~2012-03-15 17:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-15 16:18 [Qemu-devel] [PATCH] xen-mapcache: don't unmap locked entry during mapcache invalidation Julien Grall
2012-03-15 16:18 ` Julien Grall
2012-03-15 17:14 ` [Qemu-devel] " Stefano Stabellini
2012-03-15 17:14 ` Stefano Stabellini
2012-03-15 17:10 ` [Qemu-devel] " Andres Lagar-Cavilla
2012-03-15 17:10 ` Andres Lagar-Cavilla
2012-03-15 17:10 ` Olaf Hering [this message]
2012-03-15 17:10 ` Olaf Hering
2012-03-15 17:33 ` [Qemu-devel] " Stefano Stabellini
2012-03-15 17:33 ` Stefano Stabellini
2012-03-15 17:30 ` [Qemu-devel] [Xen-devel] " Tim Deegan
2012-03-15 17:30 ` Tim Deegan
2012-03-15 17:32 ` [Qemu-devel] " Andres Lagar-Cavilla
2012-03-15 17:32 ` Andres Lagar-Cavilla
2012-03-15 17:37 ` [Qemu-devel] " Tim Deegan
2012-03-15 17:37 ` Tim Deegan
2012-03-15 17:46 ` [Qemu-devel] " Stefano Stabellini
2012-03-15 17:46 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120315171056.GA20701@aepfle.de \
--to=olaf@aepfle.de \
--cc=andres@lagarcavilla.org \
--cc=julien.grall@citrix.com \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.