From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Liu Jinsong <jinsong.liu@intel.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Keir Fraser <keir@xen.org>, Jun Nakajima <jun.nakajima@intel.com>,
Tim Deegan <tim@xen.org>
Subject: Re: [PATCH] VMX: Corrections to XSA-60 fix
Date: Thu, 7 Nov 2013 11:15:04 +0000 [thread overview]
Message-ID: <527B7638.1060602@citrix.com> (raw)
In-Reply-To: <527B830402000078001008ED@nat28.tlf.novell.com>
On 07/11/13 11:09, Jan Beulich wrote:
>>>> On 07.11.13 at 11:56, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> This patch is somewhat RFC, partly because I have only compile-tested it, and
>> because of a few further questions.
>>
>> 1) Are there any other places other than unmap_domain_page() we might want to
>> put hooks? Any well behaved access should use {map,unmap}_domain_page() as
>> far as I am aware.
> Any writes done through map_domain_page_global() mappings.
Ooh yes. I will hook unmap_domain_page_global() as well
>
>> 2) What is expected to happen with Qemu mappings from dom0? As far as I am
>> aware, they can't retoactivly have their pagetable caching type changed.
> Right, so the flag should also get set when completing ioreq-s.
>
> Jan
>
Ok, but that still doesn't help coherency of emulated device state which
changes without an ioreq. Qemu scraping the framebuffer for VNC comes
to mind.
How bad would it be to have clean cacheline in RAM because of Qemu,
which is accessed as UC by the domain? I suspect the answer is "there
be dragons", and thus best avoided.
~Andrew
next prev parent reply other threads:[~2013-11-07 11:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-07 10:56 [PATCH] VMX: Corrections to XSA-60 fix Andrew Cooper
2013-11-07 11:09 ` Jan Beulich
2013-11-07 11:15 ` Andrew Cooper [this message]
2013-11-07 11:44 ` Jan Beulich
2013-11-15 16:18 ` Jan Beulich
2013-11-07 11:40 ` Andrew Cooper
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=527B7638.1060602@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=jinsong.liu@intel.com \
--cc=jun.nakajima@intel.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.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 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.