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

Re: [Xen-devel] [PATCH 07/17] x86/traps: put PV code handlers under CONFIG_PV



On Fri, Oct 12, 2018 at 08:08:19AM -0600, Jan Beulich wrote:
> >>> On 04.10.18 at 17:43, <wei.liu2@xxxxxxxxxx> wrote:
> > The trap handlers in hypervisor need to forward events to PV guests if
> > necessary. If there is no PV guest relevant code should be excluded.
> > 
> > Put code under CONFIG_PV and add ASSERT_UNREACHABLE.
> 
> -ETOOMANYIFDEFS
> 
> What's wrong with an inline stub for pv_inject_event()? This won't
> eliminate all #ifdef-s, but quite a few of them afaics.

Nothing wrong with that. I have provided a stub in my next version.

> 
> > @@ -1140,6 +1152,7 @@ static int handle_ldt_mapping_fault(unsigned int 
> > offset,
> >          if ( !guest_mode(regs) )
> >              return 0;
> >  
> > +#ifdef CONFIG_PV
> >          /* Access would have become non-canonical? Pass #GP[sel] back. */
> >          if ( unlikely(!is_canonical_address(curr->arch.pv.ldt_base + 
> > offset)) )
> >          {
> > @@ -1151,6 +1164,9 @@ static int handle_ldt_mapping_fault(unsigned int 
> > offset,
> >              /* else pass the #PF back, with adjusted %cr2. */
> >              pv_inject_page_fault(regs->error_code,
> >                                   curr->arch.pv.ldt_base + offset);
> > +#else
> > +        ASSERT_UNREACHABLE();
> > +#endif
> 
> I think here it should be the call site to gain #ifdef (around the
> entire if()), and the function as a whole should then be put in
> another #ifdef, or be moved to pv/traps.c.
> 

Done. Relevant code and call site are now put under CONFIG_PV. The
movement will be done later.

> > @@ -1494,7 +1514,9 @@ void __init do_early_page_fault(struct cpu_user_regs 
> > *regs)
> >  
> >  void do_general_protection(struct cpu_user_regs *regs)
> >  {
> > +#ifdef CONFIG_PV
> >      struct vcpu *v = current;
> > +#endif
> 
> I think this would better be resolved by moving the declaration into
> the block which has multiple references, and use plain "current" in
> the subsequent "else if()". But it's a matter of taste, I agree.

To me calling current more than necessary is bad because the resulting
machine code can end up calculating the address of cpu_info multiple
times.

Wei.

> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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