From: Razvan Cojocaru <rzvncj@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] mem_event: Allow emulating an instruction that caused a page fault
Date: Thu, 17 Jan 2013 15:16:35 +0200 [thread overview]
Message-ID: <50F7F9B3.9050206@gmail.com> (raw)
In-Reply-To: <20130117121610.GB19975@ocelot.phlegethon.org>
> Hi,
Hello Tim, thank you for taking the time to review this.
> I think there ought to be some other control to this: what if a single
> instruction accesses multiple pages, each of which would cause an access
> fault? You only get a notification of the first one, so short of
> emulating the instruction yourself in userspace I don't know how you can
> decide that it's safe.
You're right, but I can't see how this case could be handled at all
without lifting the restrictions, one page at a time. And that's
precisely what this patch aims to make unnecessary. I can't see a way
around it (not while the emulation support is limited to
hvm_emulate_one() and hvm_emulate_one_nowrite()).
> This function always operates on the currently scheduled vcpu, so you
> don't need to pass a cpu-user-regs struct all the way down the stack --
> you can just use guest_cpu_user_regs() here.
Of course. Thank you.
> I don't think this is necessary: you only need to add a field to thuiis
> file if you'll be using it from assembly code.
I thought I'd be polite and add it anyway, in case somebody will want to
use it later. Was that pollution? I'll remove it.
>> +#define MEM_EVENT_FLAG_EMULATE (1 << 5)
>
> Please add a comment saying what this flag does. I know the rest of
> this code is poorly commented, but let's try to make thing better as we
> go. :)
I will.
Thank you,
Razvan Cojocaru
prev parent reply other threads:[~2013-01-17 13:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-14 14:32 [PATCH] mem_event: Allow emulating an instruction that caused a page fault Razvan Cojocaru
2013-01-17 12:16 ` Tim Deegan
2013-01-17 13:16 ` Razvan Cojocaru [this message]
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=50F7F9B3.9050206@gmail.com \
--to=rzvncj@gmail.com \
--cc=tim@xen.org \
--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.