qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Nathan Baum <nathan@parenthephobia.org.uk>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC][PATCH] File-backed memory maps
Date: Fri, 18 Sep 2009 17:10:35 +0100	[thread overview]
Message-ID: <20090918161035.GA9059@shareable.org> (raw)
In-Reply-To: <1253286348.11717.296.camel@localhost.localdomain>

Nathan Baum wrote:
> > On architectures other than x86, sometimes data written by one process
> > is not visible to another process mapping the same file, until the
> > writing process flushes it's cache for those pages.  Whether that's
> > necessary depends on the address that pages are mapped to.  Afaik,
> > normally Linux chooses an address where this issue is avoided, but if
> > you specify it with MAP_FIXED (or whatever KVM does to map pages),
> > then there's cache coherency to deal with.

I missed out something important: Not only does the writing process
have to clean it's cache (write dirty cachelines); the reading process
has to invalidate it's cache too.

At the system call level, that means the reading process must call
msync().  Until it does that, it may still see some of the data
change, but it's not guaranteed to see all the changes.

If the writer's copying from QEMU's VRAM to a copy, during that copy,
the reading process will see something uncertain; probably not very
useful for a VNC server.  They would need to coordinate this.  Not
sure if that buys anything over whatever KVM has to do already :-)

RDP server add-ons etc. are a good idea, imho, but perhaps can be
implemented as a shared library loaded into qemu?

-- Jamie

  reply	other threads:[~2009-09-18 16:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-18 12:11 [Qemu-devel] [RFC][PATCH] File-backed memory maps Nathan Baum
2009-09-18 13:59 ` Jamie Lokier
2009-09-18 15:05   ` Nathan Baum
2009-09-18 16:10     ` Jamie Lokier [this message]
2009-09-18 15:15 ` Anthony Liguori

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=20090918161035.GA9059@shareable.org \
    --to=jamie@shareable.org \
    --cc=nathan@parenthephobia.org.uk \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).