Re: [Xen-devel] [RFC 4/4] HVM x86 deprivileged mode: Trap handlers for deprivileged mode

[Tim Deegan <tim@xxxxxxx>]

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel