From: Razvan Cojocaru <rzvncj@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: hvm_emulate_one() usage
Date: Thu, 10 Jan 2013 16:31:45 +0200 [thread overview]
Message-ID: <50EED0D1.3020006@gmail.com> (raw)
In-Reply-To: <20130110142353.GF99373@ocelot.phlegethon.org>
>> I was very much hoping to be able to do this with only one (page fault)
>> mem_event per emulated write instruction.
>
> I'm sure that can be done. The trick is to make sure the emulation
> happens in the guest context (i.e. when the guest is scheduled). You
> could do that by (e.g.) defining a new mem_access type 'single-step
> writes' where a write fault triggers a single-step emulation in the
> fault handler as well as an asynchronous mem-event.
That's what I'm doing now (albeit with the plain
MEM_EVENT_REASON_VIOLATION) - I'm emulating the write in
p2m_mem_access_check(), where I'm in the guest context, just before
putting the mem_event in the ring buffer.
The problem is, I don't want to do that. :) I want to stop certain
writes _before_ they happen, and emulating the write instruction there
first performs the write, and then notifies dom0 userspace about it.
The ideal sequence would be: 1. notify userspace about a would-be write,
2. get the reply from userspace, 3. only write if userspace said OK. The
point is that I don't know if the write should be allowed to happen or
not until userspace replies.
Thanks,
Razvan Cojocaru
next prev parent reply other threads:[~2013-01-10 14:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-28 14:34 hvm_emulate_one() usage Razvan Cojocaru
2012-12-28 22:27 ` Andrew Cooper
2012-12-28 23:29 ` Razvan Cojocaru
2013-01-10 13:16 ` Tim Deegan
2013-01-10 14:10 ` Razvan Cojocaru
2013-01-10 14:23 ` Tim Deegan
2013-01-10 14:31 ` Razvan Cojocaru [this message]
2013-01-10 14:58 ` Tim Deegan
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=50EED0D1.3020006@gmail.com \
--to=rzvncj@gmail.com \
--cc=tim@xen.org \
--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 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.