All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Deegan <tim@xen.org>
To: Ben Catterall <Ben.Catterall@citrix.com>
Cc: xen-devel@lists.xensource.com, keir@xen.org,
	ian.campbell@citrix.com, george.dunlap@eu.citrix.com,
	andrew.cooper3@citrix.com, jbeulich@suse.com
Subject: Re: [RFC 4/4] HVM x86 deprivileged mode: Trap handlers for deprivileged mode
Date: Mon, 17 Aug 2015 15:58:50 +0100	[thread overview]
Message-ID: <20150817145850.GA42311@deinos.phlegethon.org> (raw)
In-Reply-To: <55D1E8AE.1080005@citrix.com>

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:
> >> This should happen in paging_fault() so it can guard the
> >> shadow-pagetable paths too.  Once it's there, it'll need a check for
> >> is_hvm_vcpu() as well as for user_mode.  Maybe have a helper function
> >> 'is_hvm_deprivileged_vcpu()' to do both checks, also used in
> >> hvm_deprivileged_check_trap() &c.
> I've moved this and now need to add shadow page table support as this 
> currently only supports HAP.

Thanks.  There shouldn't be very much work to do for this -- after all
we're not running in the guest's pagetables so the actual shadow PT
mechanism won't be needed.  Maybe just a common helper function called
from the shadow & hap monitor-table builders?

> >> 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.

Cheers,

Tim.

  reply	other threads:[~2015-08-17 14:58 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 [this message]
2015-08-17 15:14           ` Jan Beulich
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=20150817145850.GA42311@deinos.phlegethon.org \
    --to=tim@xen.org \
    --cc=Ben.Catterall@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@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.