[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 0/2] x86/HVM: Properly handle SMAP check in certain cases




> -----Original Message-----
> From: Pasi Kärkkäinen [mailto:pasik@xxxxxx]
> Sent: Tuesday, July 29, 2014 3:03 PM
> To: Wu, Feng
> Cc: xen-devel@xxxxxxxxxxxxx; tim@xxxxxxx; keir@xxxxxxx; jbeulich@xxxxxxxx;
> linux@xxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH v3 0/2] x86/HVM: Properly handle SMAP check
> in certain cases
> 
> On Tue, Jan 09, 2001 at 06:52:05AM +0800, Feng Wu wrote:
> 
> Hello Feng.. your clock seems to be messed up :) 2001..
> 

Hmmm, thanks for notifying this. since this is a new HW platform, every time I 
reboot it, its clock will go back to 2001. 
Sorry I forget to set it to the correct time.

Thanks,
Feng

> 
> -- Pasi
> 
> 
> > This patch set fixs a issue found by Sander Eikelenboom. Here is the log
> > when this issue occurs:
> >
> > (d2)  Booting from Hard Disk...
> > (d2)  Booting from 0000:7c00
> > (XEN) irq.c:380: Dom1 callback via changed to Direct Vector 0xf3
> > (XEN) irq.c:380: Dom2 callback via changed to Direct Vector 0xf3
> > (XEN) Segment register inaccessible for d1v0
> > (XEN) (If you see this outside of debugging activity, please report to
> xen-devel@xxxxxxxxxxxxxxxxxxxx)
> >
> > And here is the Xen call trace:
> > (XEN) [<ffff82d0801dc9c5>] vmx_get_segment_register+0x4d/0x422
> > (XEN) [<ffff82d0801f4415>] guest_walk_tables_3_levels+0x189/0x520
> > (XEN) [<ffff82d0802204a8>] hap_p2m_ga_to_gfn_3_levels+0x158/0x2c2
> > (XEN) [<ffff82d08022062e>] hap_gva_to_gfn_3_levels+0x1c/0x1e
> > (XEN) [<ffff82d0801ec215>] paging_gva_to_gfn+0xb8/0xce
> > (XEN) [<ffff82d0801ba88d>] __hvm_copy+0x87/0x354
> > (XEN) [<ffff82d0801bac7c>] hvm_copy_to_guest_virt_nofault+0x1e/0x20
> > (XEN) [<ffff82d0801bace5>] copy_to_user_hvm+0x67/0x87
> > (XEN) [<ffff82d08016237c>] update_runstate_area+0x98/0xfb
> > (XEN) [<ffff82d0801623f0>] _update_runstate_area+0x11/0x39
> > (XEN) [<ffff82d0801634db>] context_switch+0x10c3/0x10fa
> > (XEN) [<ffff82d080126a19>] schedule+0x5a8/0x5da
> > (XEN) [<ffff82d0801297f9>] __do_softirq+0x81/0x8c
> > (XEN) [<ffff82d080129852>] do_softirq+0x13/0x15
> > (XEN) [<ffff82d08015f70a>] idle_loop+0x67/0x77
> >
> > We need get guest's SS register via hvm_get_segment_register()
> > to do the SMAP checking, however, in these two cases, we cannot
> > do it that way since it is between setting 'current' and reloading
> > the VMCS context for it. As an alternative, here we treat these
> > accesses as implicit supervisor mode access, hence SMAP checking is
> > always need.
> >
> > V2:
> > Remove ' VCPUOP_enable_smap_check_vcpu_time_memory_area' hypercall,
> > hence always do the SMAP checking for the secondary system time.
> >
> > V3:
> > - Add smap_policy_change() to change the smap policy, which will
> > returen the old value.
> > - Use enum to define the smap policy.
> > - Drop 'Case SMAP_CHECK_DISABLED' in guest_walk_tables(), and add
> > 'ASSERT(v->arch.smap_check_policy == SMAP_CHECK_DISABLED)' in the
> > default case instead.
> >
> > Feng Wu (2):
> >   x86/hvm: Always do SMAP check when updating runstate_guest(v)
> >   x86/hvm: Always do SMAP check when updating secondary system time
> for
> >     guest
> >
> >  xen/arch/x86/domain.c        | 26 ++++++++++++++++++++++----
> >  xen/arch/x86/mm/guest_walk.c | 39
> ++++++++++++++++++++++++++-------------
> >  xen/arch/x86/time.c          | 10 +++++++++-
> >  xen/include/asm-x86/domain.h | 19 +++++++++++++++++--
> >  4 files changed, 74 insertions(+), 20 deletions(-)
> >
> > --
> > 1.8.3.1
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.