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

RE: [Xen-devel] [Patch] Add hardware CR8 acceleration for TPR accessing


  • To: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>, "Betak, Travis" <travis.betak@xxxxxxx>
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Tue, 24 Oct 2006 11:55:06 +0200
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 24 Oct 2006 02:55:57 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acb2poaTahW5y1OoRpGOMqtXL3GS/wAp2u8wAAD9/gA=
  • Thread-topic: [Xen-devel] [Patch] Add hardware CR8 acceleration for TPR accessing

 

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Cui, Dexuan
> Sent: 24 October 2006 10:35
> To: Betak, Travis
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [Patch] Add hardware CR8 
> acceleration for TPR accessing
> 
> Hi, Travis,
> Is there anything in SVM similar to TPP-threshold in VMX?
> If no, I really need to find a better place for the 
> vlapic_update_tpr_threshold().

I don't think that's the question/statement: any code in hvm directory should 
be guaranteed to be callable by both Intel and AMD code. The code you've just 
added makes direct use of the vmwrite instruction, which there isn't a 
corresponding instruction for in AMD processors. 

[Whether it makes sense to call it for an AMD processor is a completely 
different question - it's the principle that the code in the hvm directory 
should be "architecture independent"]. 

You may need to implement another function-pointer in the hvm structure to be 
able to do this... 

--
Mats
> 
> Thanks
>  -- Dexuan
> 
> -----Original Message-----
> From: Travis Betak [mailto:travis.betak@xxxxxxx] 
> Sent: 2006年10月23日 21:23
> To: Cui, Dexuan
> Cc: Keir.Fraser@xxxxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [Patch] Add hardware CR8 
> acceleration for TPR accessing
> 
> On Mon, 23 Oct 2006, Cui, Dexuan wrote:
> 
> > diff -r 8113c55a6efd xen/arch/x86/hvm/vlapic.c
> > --- a/xen/arch/x86/hvm/vlapic.c     Sun Oct 22 17:38:59 2006 +0100
> > +++ b/xen/arch/x86/hvm/vlapic.c     Mon Oct 23 14:03:11 2006 +0800
> > @@ -29,6 +29,7 @@
> >  #include <asm/hvm/hvm.h>
> >  #include <asm/hvm/io.h>
> >  #include <asm/hvm/support.h>
> > +#include <asm/hvm/vmx/vmx.h>
> >
> >  #include <xen/lib.h>
> >  #include <xen/sched.h>
> > @@ -119,6 +120,20 @@ uint32_t vlapic_update_ppr(struct vlapic
> >                  vlapic, ppr, isr, isrv);
> >
> >      return ppr;
> > +}
> > +
> > +void vlapic_update_tpr_threshold(struct vlapic *vlapic)
> > +{
> > +#ifdef __x86_64__
> > +    int highest_irr = vlapic_find_highest_irr(vlapic);
> > +    int tpr = vlapic_get_reg(vlapic, APIC_TASKPRI) & 0xF0;
> > +
> > +    if ( highest_irr == -1 )
> > +        __vmwrite( TPR_THRESHOLD, 0);
> > +    else
> > +        __vmwrite(TPR_THRESHOLD,
> > +            highest_irr > tpr ? (tpr >> 4) : (highest_irr >> 4) );
> > +#endif
> >  }
> >
> >  /* This only for fixed delivery mode */
> 
> Hi, Dexuan,
> 
> Do we want architectual-specific code creeping into the generic HVM
> layer?  This routine is only called in VMX code but I don't think this
> the the right place for this code.
> 
>   --travis
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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