All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH 3/5] vtdt: Modify vlapic code to add vtdt support
Date: Tue, 14 Dec 2010 09:21:03 +0000	[thread overview]
Message-ID: <C92CE77F.CCC9%keir@xen.org> (raw)
In-Reply-To: <F26D193E20BBDC42A43B611D1BDEDE7124EADAFA5E@shsmsx502.ccr.corp.intel.com>

On 14/12/2010 03:27, "Wei, Gang" <gang.wei@intel.com> wrote:

> @@ -643,7 +669,11 @@ static int vlapic_write(struct vcpu *v,
>          break;
>  
>      case APIC_LVTT:         /* LVT Timer Reg */
> +        destroy_periodic_time(&vlapic->pt);
>          vlapic->pt.irq = val & APIC_VECTOR_MASK;
> +        vlapic_set_reg(vlapic, APIC_TMICT, 0);
> +        vlapic_set_reg(vlapic, APIC_TMCCT, 0);
> +        vlapic->hw.tdt_msr = 0;

Writing any value to LVTT zaps TMICT,TMCCT,MSR_TDT? That seems pretty
unlikely to me! This obviously has effects on behaviour outside TDT
emulation as it affects TMICT/TMCCT emulation. Looks dangerous, as well as
wrong.

Also I now notice that this patch is not against tip of xen-unstable, as
these changes should be to new function vlapic_reg_write().

 -- Keir

>      case APIC_LVTTHMR:      /* LVT Thermal Monitor */
>      case APIC_LVTPC:        /* LVT Performance Counter */
>      case APIC_LVT0:         /* LVT LINT0 Reg */
> @@ -666,6 +696,9 @@ static int vlapic_write(struct vcpu *v,
>      {
>          uint64_t period;
>  
> +        if ( !vlapic_lvtt_oneshot(vlapic) && !vlapic_lvtt_period(vlapic) )
> +            break;
> +
>          vlapic_set_reg(vlapic, APIC_TMICT, val);
>          if ( val == 0 )
>          {
> @@ -746,6 +779,73 @@ void vlapic_msr_set(struct vlapic *vlapi
>  
>      HVM_DBG_LOG(DBG_LEVEL_VLAPIC,
>                  "apic base msr is 0x%016"PRIx64, vlapic->hw.apic_base_msr);
> +}
> +
> +uint64_t  vlapic_tdt_msr_get(struct vlapic *vlapic)
> +{
> +    if ( !vlapic_lvtt_tdt(vlapic) )
> +        return 0;
> +
> +    return vlapic->hw.tdt_msr;
> +}
> +
> +void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value)
> +{
> +    uint64_t guest_tsc;
> +    uint64_t guest_time;
> +    struct vcpu *v = vlapic_vcpu(vlapic);
> +
> +    /* may need to exclude some other conditions like vlapic->hw.disabled */
> +    if ( !vlapic_lvtt_tdt(vlapic) )
> +    {
> +        HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "ignore tsc deadline msr write");
> +        return;
> +    }
> +    
> +    /* new_value = 0, >0 && <= now, > now */
> +    guest_tsc = hvm_get_guest_tsc(v);
> +    guest_time = hvm_get_guest_time(v);
> +    if ( value > guest_tsc )
> +    {
> +        uint64_t delta = value - v->arch.hvm_vcpu.cache_tsc_offset;
> +        delta = gtsc_to_gtime(v->domain, delta);
> +        delta = max_t(s64, delta - guest_time, 0);
> +
> +        HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "delta[0x%016"PRIx64"]", delta);
> +
> +        vlapic->hw.tdt_msr = value;
> +        /* .... reprogram tdt timer */
> +        create_periodic_time(v, &vlapic->pt, delta, 0,
> +                             vlapic->pt.irq, vlapic_tdt_pt_cb,
> +                             &vlapic->timer_last_update);
> +        vlapic->timer_last_update = vlapic->pt.last_plt_gtime;
> +    }
> +    else
> +    {
> +        vlapic->hw.tdt_msr = 0;
> +
> +        /* trigger a timer event if needed */
> +        if ( value > 0 )
> +        {
> +            create_periodic_time(v, &vlapic->pt, 0, 0,
> +                                 vlapic->pt.irq, vlapic_tdt_pt_cb,
> +                                 &vlapic->timer_last_update);
> +            vlapic->timer_last_update = vlapic->pt.last_plt_gtime;
> +        }
> +        else
> +        {
> +            /* .... stop tdt timer */
> +            destroy_periodic_time(&vlapic->pt);
> +        }
> +
> +        HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "value[0x%016"PRIx64"]", value);
> +    }
> +
> +    HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER,
> +                "tdt_msr[0x%016"PRIx64"],"
> +                " gtsc[0x%016"PRIx64"],"
> +                " gtime[0x%016"PRIx64"]",
> +                vlapic->hw.tdt_msr, guest_tsc, guest_time);
>  }
>  
>  static int __vlapic_accept_pic_intr(struct vcpu *v)
> @@ -860,6 +960,17 @@ void vlapic_reset(struct vlapic *vlapic)
>      destroy_periodic_time(&vlapic->pt);
>  }
>  
> +static void lapic_tdt_rearm(struct vlapic *s)
> +{
> +    uint64_t tdt_msr = vlapic_tdt_msr_get(s);
> +
> +    s->pt.irq = vlapic_get_reg(s, APIC_LVTT) & APIC_VECTOR_MASK;
> +    if ( tdt_msr == 0)
> +       return;
> +
> +    vlapic_tdt_msr_set(s, tdt_msr);
> +}
> +
>  /* rearm the actimer if needed, after a HVM restore */
>  static void lapic_rearm(struct vlapic *s)
>  {
> @@ -953,7 +1064,10 @@ static int lapic_load_regs(struct domain
>          return -EINVAL;
>  
>      vlapic_adjust_i8259_target(d);
> -    lapic_rearm(s);
> +    if ( vlapic_lvtt_tdt(s) )
> +        lapic_tdt_rearm(s);
> +    else
> +        lapic_rearm(s);
>      return 0;
>  }
>  
> diff -r d042ca4c6b68 xen/include/asm-x86/hvm/vlapic.h
> --- a/xen/include/asm-x86/hvm/vlapic.h Thu Dec 09 22:33:02 2010 +0800
> +++ b/xen/include/asm-x86/hvm/vlapic.h Thu Dec 09 22:33:06 2010 +0800
> @@ -90,6 +90,8 @@ void vlapic_reset(struct vlapic *vlapic)
>  void vlapic_reset(struct vlapic *vlapic);
>  
>  void vlapic_msr_set(struct vlapic *vlapic, uint64_t value);
> +void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t value);
> +uint64_t vlapic_tdt_msr_get(struct vlapic *vlapic);
>  
>  int vlapic_accept_pic_intr(struct vcpu *v);
>  
> diff -r d042ca4c6b68 xen/include/public/arch-x86/hvm/save.h
> --- a/xen/include/public/arch-x86/hvm/save.h Thu Dec 09 22:33:02 2010 +0800
> +++ b/xen/include/public/arch-x86/hvm/save.h Thu Dec 09 22:33:06 2010 +0800
> @@ -265,6 +265,7 @@ struct hvm_hw_lapic {
>      uint64_t             apic_base_msr;
>      uint32_t             disabled; /* VLAPIC_xx_DISABLED */
>      uint32_t             timer_divisor;
> +    uint64_t             tdt_msr;
>  };
>  
>  DECLARE_HVM_SAVE_TYPE(LAPIC, 5, struct hvm_hw_lapic);
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

  parent reply	other threads:[~2010-12-14  9:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-14  3:27 [PATCH 3/5] vtdt: Modify vlapic code to add vtdt support Wei, Gang
2010-12-14  7:35 ` Keir Fraser
2010-12-14  8:22   ` Wei, Gang
2010-12-14  8:48     ` Keir Fraser
2010-12-14  9:13       ` Wei, Gang
2010-12-14  9:59         ` Keir Fraser
2010-12-14 10:01           ` Keir Fraser
2010-12-14 10:18             ` Tim Deegan
2010-12-14  9:21 ` Keir Fraser [this message]
2010-12-14  9:30   ` Wei, Gang
2010-12-14  9:56     ` Keir Fraser
2010-12-14 10:13       ` Wei, Gang
2010-12-14 10:29 ` Wei, Gang

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=C92CE77F.CCC9%keir@xen.org \
    --to=keir@xen.org \
    --cc=gang.wei@intel.com \
    --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.