From: "Jan Beulich" <JBeulich@suse.com>
To: Razvan Cojocaru <rcojocaru@bitdefender.com>
Cc: kevin.tian@intel.com, ian.campbell@citrix.com,
stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
eddie.dong@intel.com, tim@xen.org, jun.nakajima@intel.com,
xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc
Date: Fri, 29 Aug 2014 10:27:06 +0100 [thread overview]
Message-ID: <5400638A020000780002EFD6@mail.emea.novell.com> (raw)
In-Reply-To: <54002F43.4070802@bitdefender.com>
>>> On 29.08.14 at 09:44, <rcojocaru@bitdefender.com> wrote:
> I do understand the preference for a VCPU-based mechanism from a
> concurrency point of view, but that would simply potentially fail for
> us, hence defeating the purpose of the patch. I'm also not sure how that
> would be useful in the general case either, since the same problem that
> applies to us would seem to apply to the general case as well.
Yeah, the whole thing probably needs a bit more thinking so that the
interface doesn't end up being a BitDefender-special. Indeed together
with the address space qualification, the interface might not be very
useful when made vCPU-bound. And taking it a little further into the
"generic" direction, allowing this to only inject #PF doesn't make a
very nice interface either. Plus we already have HVMOP_inject_trap,
i.e. your first line of thinking (and eventual explaining as the
motivation for a patch) should be why that can't be used.
Jan
next prev parent reply other threads:[~2014-08-29 9:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-28 11:47 [PATCH RFC V9 1/5] xen: Emulate with no writes Razvan Cojocaru
2014-08-28 11:47 ` [PATCH RFC V9 2/5] xen: Optimize introspection access to guest state Razvan Cojocaru
2014-08-28 11:48 ` [PATCH RFC V9 3/5] xen, libxc: Force-enable relevant MSR events Razvan Cojocaru
2014-08-28 11:48 ` [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc Razvan Cojocaru
2014-08-28 12:03 ` Jan Beulich
2014-08-28 12:08 ` Razvan Cojocaru
2014-08-28 12:11 ` Jan Beulich
2014-08-28 12:23 ` Razvan Cojocaru
2014-08-28 12:37 ` Razvan Cojocaru
2014-08-29 7:44 ` Razvan Cojocaru
2014-08-29 9:27 ` Jan Beulich [this message]
2014-09-01 7:36 ` Razvan Cojocaru
2014-09-01 9:08 ` Jan Beulich
2014-09-01 11:54 ` Razvan Cojocaru
2014-09-01 12:05 ` Jan Beulich
2014-09-02 9:18 ` Razvan Cojocaru
2014-09-02 9:33 ` Jan Beulich
2014-09-02 9:44 ` Razvan Cojocaru
2014-09-02 10:08 ` Jan Beulich
2014-09-02 13:24 ` Tim Deegan
2014-09-09 16:57 ` George Dunlap
2014-09-09 17:39 ` Razvan Cojocaru
2014-09-09 18:38 ` Tamas K Lengyel
2014-09-10 8:09 ` Razvan Cojocaru
2014-09-10 8:48 ` Andrew Cooper
2014-09-10 8:55 ` Razvan Cojocaru
2014-09-10 9:34 ` Andrew Cooper
2014-09-10 10:39 ` George Dunlap
2014-09-10 10:49 ` Razvan Cojocaru
2014-09-09 20:14 ` Tim Deegan
2014-09-10 9:30 ` Razvan Cojocaru
2014-09-10 9:59 ` Tamas K Lengyel
2014-09-10 10:44 ` Tim Deegan
2014-08-28 11:48 ` [PATCH RFC V9 5/5] xen: Handle resumed instruction based on previous mem_event reply Razvan Cojocaru
2014-08-28 12:09 ` Jan Beulich
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=5400638A020000780002EFD6@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=eddie.dong@intel.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=rcojocaru@bitdefender.com \
--cc=stefano.stabellini@eu.citrix.com \
--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 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).