|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 1/5] x86: allow reading MSR_IA32_TSC with XENPF_resource_op
On 23/01/15 14:28, Jan Beulich wrote:
>>>> On 23.01.15 at 14:40, <chao.p.peng@xxxxxxxxxxxxxxx> wrote:
>> @@ -133,10 +135,39 @@ static void resource_access(void *info)
>> switch ( entry->u.cmd )
>> {
>> case XEN_RESOURCE_OP_MSR_READ:
>> - ret = rdmsr_safe(entry->idx, entry->val);
>> + if ( unlikely(entry->idx == MSR_IA32_TSC) ) {
>> + /* Return scaled time instead of raw timestamp */
>> + entry->val = get_s_time_fixed(tsc);
> This is going to be bogus when happening on the first entry.
> Either disallow it, or rdtscll() here if tsc == 0.
>
>> + ret = 0;
>> + }
>> + else
>> + {
>> + unsigned long irqflags;
>> + /*
>> + * If next entry is MSR_IA32_TSC read, then the actual
>> rdtscll
>> + * is performed together with current entry, with IRQ
>> disabled.
>> + */
>> + bool_t read_tsc = (i < ra->nr_done - 1 &&
>> + unlikely(entry[1].idx == MSR_IA32_TSC &&
>> + entry[1].u.cmd ==
>> XEN_RESOURCE_OP_MSR_READ));
> Just like you do the rdtscll() without regard to rc (which is fine),
> I don't think you need that last part of the condition.
>
>> --- a/xen/include/public/platform.h
>> +++ b/xen/include/public/platform.h
>> @@ -540,6 +540,16 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_core_parking_t);
>> #define XEN_RESOURCE_OP_MSR_READ 0
>> #define XEN_RESOURCE_OP_MSR_WRITE 1
>>
>> +/*
>> + * Specially handled MSRs:
>> + * - MSR_IA32_TSC
>> + * READ: Returns the scaled system time(ns) instead of raw timestamp. In
>> + * multiple entry case, if other MSR read is followed by a
>> MSR_IA32_TSC
>> + * read, then both reads are guaranteed to be performed atomically
>> (with
>> + * IRQ disabled). The return time indicates the point of reading that
>> MSR.
>> + * WRITE: Not supported.
>> + */
> So before adding this I'd really like to once again understand what
> the consumer of this is going to use this for: The scaled system time
> normally isn't very useful to user mode code, hence whether we
> return ticks or nanoseconds doesn't seem to make a big difference -
> unless user mode code is expected to only ever look at the delta of
> two such values. In which case I'd consider obfuscating the real
> value by some artificial (and perhaps randomized at boot time) bias.
A delta is precisely the usecase. Calculating the actual memory
bandwidth requires two MSR samples and the time in between them.
Originally, the time was calculated with a usleep() library call but I
objected to this because of scheduling getting in the way of measuring
an accurate time delta.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |