From: Tim Deegan <tim@xen.org>
To: Razvan Cojocaru <rzvncj@gmail.com>
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH V2] mem_event: Allow emulating an instruction that caused a page fault
Date: Thu, 24 Jan 2013 11:05:04 +0000 [thread overview]
Message-ID: <20130124110504.GA18850@ocelot.phlegethon.org> (raw)
In-Reply-To: <50FEA60E.2000503@gmail.com>
At 16:45 +0200 on 22 Jan (1358873134), Razvan Cojocaru wrote:
> >The only properly safe way to allow exactly one exception to your rules
> >is to emulate the instruction in user-space. (Well, that or somehow
> >move your policy into Xen and do the emulation there, but I'm quite
> >strongly opposed to that).
>
> Is there an example of that somewhere in the Xen source code tree?
I don't think so.
It occurs to me that if you're willing to rely on the Xen x86_emulate()
emulator, the model that we use for emulated MMIO might be better.
There, Xen emulates the instruction directly in the fault handler and
sends individual memory accesses to qemu for emulation. qemu receives
them as a series of ioreqs (basically, address/size/data tuples).
So you could, for example:
- invent up a new p2m type (probably based very closely on p2m_ram_ro,
maybe you could even just use p2m_ram_ro).
- Use the HVMOP_set_mem_type to mark the pages you want readonly.
- Use Julien Grall's new ioreq interfaces to register your helper
as the handler for the pages you care about.
Then your user-space helper will get told about each actual write,
rather than each faulting instruction. If the write is OK, the helper
will map the target address and do the write.
Have a look at, e.g.
http://lists.xen.org/archives/html/xen-devel/2012-08/msg01767.html
for Julien's multiple-ioreq-handlers code; I'm not sure what the
current state of that is, except that it doesn't seem to be checked in
yet.
Cheers,
Tim.
next prev parent reply other threads:[~2013-01-24 11:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.21624.1358431706.1399.xen-devel@lists.xen.org>
2013-01-17 15:38 ` [PATCH V2] mem_event: Allow emulating an instruction that caused a page fault Andres Lagar-Cavilla
2013-01-17 15:50 ` Razvan Cojocaru
2013-01-21 23:13 ` Razvan Cojocaru
2013-01-22 12:31 ` Tim Deegan
2013-01-22 12:53 ` Razvan Cojocaru
2013-01-22 13:20 ` Tim Deegan
2013-01-22 13:47 ` Razvan Cojocaru
2013-01-22 14:02 ` Andres Lagar-Cavilla
2013-01-22 14:22 ` Razvan Cojocaru
2013-01-22 14:26 ` Tim Deegan
2013-01-22 14:45 ` Razvan Cojocaru
2013-01-24 11:05 ` Tim Deegan [this message]
2013-01-24 11:34 ` Razvan Cojocaru
2013-01-17 14:02 Razvan Cojocaru
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=20130124110504.GA18850@ocelot.phlegethon.org \
--to=tim@xen.org \
--cc=andreslc@gridcentric.ca \
--cc=rzvncj@gmail.com \
--cc=xen-devel@lists.xen.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).