On Thu, Jan 22, 2015 at 02:09:37PM +0000, Jan Beulich wrote:
> >>> On 22.01.15 at 15:03, <andrew.coop...@citrix.com> wrote:
> > On 22/01/15 13:36, Jan Beulich wrote:
> >>>>> On 22.01.15 at 13:53, <chao.p.p...@linux.intel.com> wrote:
> >>> On Thu, Jan 22, 2015 at 11:20:15AM +0000, Jan Beulich wrote:
> >>>>>>> On 21.01.15 at 12:19, <chao.p.p...@linux.intel.com> wrote:
> >>>>> --- a/xen/arch/x86/platform_hypercall.c
> >>>>> +++ b/xen/arch/x86/platform_hypercall.c
>
> > Having said this, the only useful timestamp will be at the same point as
> > performing the MSR read. Having a 3rd operation tacked on the end to
> > get a timestamp will be some arbitrary time later, especially if
> > interrupts are enabled.
>
> Perhaps the latching of NOW() could happen with the MSR read, and
> the latched value then be stored upon encountering the respective
> slot? That would also allow further limiting the interrupts disabled
> period.
Except that MSR_IA32_TSC will looks heterogeneous. But since we already
treat it as a special case, I have no problem here. And if we do so,
even the first patch to add irq_disable ability is not needed. Sounds to
me that the MSR_IA32_TSC read should always imply irq disabled. Codes
would be like this:
case XEN_RESOURCE_OP_MSR_READ:
if ( unlikely(entry->idx == MSR_IA32_TSC) )
{
entry->val = get_s_time_fixed(tsc);
ret = 0;
}
else
{
bool_t read_tsc = 0;
if ( i < ra->nr_done - 1 )
{
xenpf_resource_entry_t *next = ra->entries + i + 1;
if ( unlikely(next->idx == MSR_IA32_TSC) )
read_tsc = 1;
}
if ( unlikely(read_tsc) )
local_irq_save(irqflags);
ret = rdmsr_safe(entry->idx, entry->val);
if ( unlikely(read_tsc) )
{
rdtscll(tsc);
local_irq_restore(irqflags);
}
}
break;
case XEN_RESOURCE_OP_MSR_WRITE:
Chao
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
