All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Ben Catterall <Ben.Catterall@citrix.com>, Tim Deegan <tim@xen.org>
Cc: george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	xen-devel@lists.xensource.com, keir@xen.org,
	ian.campbell@citrix.com
Subject: Re: [RFC 4/4] HVM x86 deprivileged mode: Trap handlers for deprivileged mode
Date: Mon, 17 Aug 2015 09:14:22 -0600	[thread overview]
Message-ID: <55D2166E020000780009B6B8@prv-mh.provo.novell.com> (raw)
In-Reply-To: <20150817145850.GA42311@deinos.phlegethon.org>

>>> On 17.08.15 at 16:58, <tim@xen.org> wrote:
> At 14:59 +0100 on 17 Aug (1439823550), Ben Catterall wrote:
>> On 11/08/15 11:33, Ben Catterall wrote:
>> > On 10/08/15 11:07, Tim Deegan wrote:
>> >> I wonder whether it would be better to switch to an IDT with all
>> >> unacceptable traps stubbed out, rather than have to blacklist them all
>> >> separately.  Probably not - this check is cheap, and maintaining the
>> >> parallel tables would be a pain.
>> >>
>> >> Or maybe there's some single point upstream of here, in the asm
>> >> handlers, that would catch all the cases where this check is needed?
>> >>
>> > Yep, I think this can be done.
>> Had a deeper look at this. There is a point where all exceptions come in 
>> in the asm (handle_exception in entry.S) and we could branch out at this 
>> point. It does mean that we'd treat _all_ exceptions that occur in this 
>> mode the same way whereas the current way means that we can treat them 
>> differently (e.g. get __func__). So, should I make all exceptions go to 
>> the same point or keep as is?
> 
> I think trap them all at the same point, unless you plan to have any
> exceptions that don't just kill the guest.  I don't think you do, do
> you?
> 
> This code is really Jan and Andrew's area, though.

And I think that deciding one way or the other here isn't necessary
at this point in time. Once there is a clear picture of whether the
route being explored here is actually usable, we can decide which
one is the better model. For now I'd recommend using whatever is
cheaper to implement.

Jan

  reply	other threads:[~2015-08-17 15:14 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06 16:45 [RFC 0/4] HVM x86 enhancements to run Xen deprivileged mode operations Ben Catterall
2015-08-06 16:45 ` [RFC 1/4] HVM x86 deprivileged mode: Page allocation helper Ben Catterall
2015-08-06 19:22   ` Andrew Cooper
2015-08-07  9:57     ` Ben Catterall
2015-08-07 13:14       ` Andrew Cooper
2015-08-10  8:50       ` Tim Deegan
2015-08-10  8:52         ` Tim Deegan
2015-08-10  8:55           ` Andrew Cooper
2015-08-10 10:08             ` Tim Deegan
2015-08-06 16:45 ` [RFC 2/4] HVM x86 deprivileged mode: Create deprivileged page tables Ben Catterall
2015-08-06 19:52   ` Andrew Cooper
2015-08-07 13:19     ` Ben Catterall
2015-08-07 15:20       ` Andrew Cooper
2015-08-06 16:45 ` [RFC 3/4] HVM x86 deprivileged mode: Code for switching into/out of deprivileged mode Ben Catterall
2015-08-06 20:55   ` Andrew Cooper
2015-08-07 12:51     ` Ben Catterall
2015-08-07 13:08       ` David Vrabel
2015-08-07 14:24       ` Andrew Cooper
2015-08-11  9:45     ` Ian Campbell
2015-08-10  9:49   ` Tim Deegan
2015-08-10 10:14     ` Andrew Cooper
2015-08-11  9:55       ` Tim Deegan
2015-08-11 16:51         ` Ben Catterall
2015-08-11 17:05           ` Tim Deegan
2015-08-11 17:19             ` Andrew Cooper
2015-08-11 18:29               ` Boris Ostrovsky
2015-08-12 13:29                 ` Andrew Cooper
2015-08-12 13:33                   ` Andrew Cooper
2015-08-17 13:53                     ` Ben Catterall
2015-08-17 15:07                       ` Tim Deegan
2015-08-17 15:17                         ` Jan Beulich
2015-08-18 10:25                           ` Ben Catterall
2015-08-18 10:26                             ` Ben Catterall
2015-08-18 14:22                               ` Jan Beulich
2015-08-18 16:55                         ` Andrew Cooper
2015-08-19 10:36                           ` Ben Catterall
2015-08-12 10:10               ` Jan Beulich
2015-08-12 13:22             ` Ben Catterall
2015-08-12 13:26               ` Tim Deegan
2015-08-20 14:42       ` Ben Catterall
2015-08-11 10:35     ` Ben Catterall
2015-08-06 16:45 ` [RFC 4/4] HVM x86 deprivileged mode: Trap handlers for " Ben Catterall
2015-08-06 21:24   ` Andrew Cooper
2015-08-07 12:32     ` Ben Catterall
2015-08-07 13:19       ` Andrew Cooper
2015-08-07 13:26         ` Ben Catterall
2015-08-10 10:07   ` Tim Deegan
2015-08-11 10:33     ` Ben Catterall
2015-08-17 13:59       ` Ben Catterall
2015-08-17 14:58         ` Tim Deegan
2015-08-17 15:14           ` Jan Beulich [this message]
2015-08-12  9:50 ` [RFC 0/4] HVM x86 enhancements to run Xen deprivileged mode operations Jan Beulich
2015-08-12 11:27   ` Ben Catterall

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=55D2166E020000780009B6B8@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=Ben.Catterall@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=keir@xen.org \
    --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.