All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 01 Sep 2014 10:08:56 +0100	[thread overview]
Message-ID: <540453C8020000780002F59C@mail.emea.novell.com> (raw)
In-Reply-To: <540421E1.9020505@bitdefender.com>

>>> On 01.09.14 at 09:36, <rcojocaru@bitdefender.com> wrote:
> On 08/29/2014 12:27 PM, Jan Beulich wrote:
>>>>> 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.
> 
> I'd say that it's memory-introspection specific rather than 3rd-party
> vendor specific. Without this this patch, memory-introspection support
> in general is impacted / less flexible, since there's no other way to
> bring swapped out pages back in.
> 
> For all the reasons you've explained (at least as far as I understand
> it) there's not much room to go more generic - so maybe just renaming
> the libxc wrapper to something more specific (
> xc_domain_request_usermode_pagefault?) is the solution here?

Maybe, but only after you explained why the existing interface can
neither be used nor suitably extended.

Jan

  reply	other threads:[~2014-09-01  9:09 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
2014-09-01  7:36             ` Razvan Cojocaru
2014-09-01  9:08               ` Jan Beulich [this message]
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=540453C8020000780002F59C@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 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.