lkml.org 
[lkml]   [2007]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Xen & VMI?
    From
    Date
    On Wed, 2007-03-07 at 01:17 -0800, Zachary Amsden wrote:
    > Ingo Molnar wrote:
    > > For example, VMI_CALL_SetAlarm takes a 'cycles' argument. Cycles is a
    > > quite bad unit for an API, it should be absolute time, nanosec or
    > > picosec based instead. We could easily see CPUs that have /no concept of
    > >
    >
    > Actually, putting the unit in terms of cycles is more portable and
    > flexible. Rather than perform a conversion from cycles to
    > nano/femto/pico seconds, the raw cycle count is exposed, along with the
    > current clock frequency. This allows the timer infrastructure to merely
    > do one conversion, from cycles to real time, rather than converting to
    > an arbitrary time unit which may change with operating systems and time
    > and thus break the ABI.

    Putting the unit in terms of cycles is just ugly. Virtual hardware
    should provide the easiest interface and in case of time this _IS_
    nanoseconds.

    nanoseconds is neither an arbitrary time unit nor will it change anytime
    soon to femtoseconds. So your argument that the ABI might break is just
    a strawman.

    The cycles conversion gets ugly as hell, as you want to have absolute
    time for your clock event reprogramming. This requires 128 bit math in
    the reprogramming path for nothing and I'm not going to put it there.

    Even worse on a Linux host we would convert ktime_t to some virtual
    hardware clock on the guest side, feed it through paravirt to the host
    and convert it back to ktime_t as the host uses an hrtimer to schedule
    the next guest event.

    The whole rush of paravirt ops leads to an arbitrary number of virtual
    clock source and clock event devices instead of having one virtual
    silicon with a sane design and a per hypervisor backend. Paravirtualized
    kernels should provide _sane_ silicon emulations rather than dumping
    more crap on the kernel developers by competing with the real silicon
    vendors for the BDHA (Brain Damaged Hardware Award).

    tglx


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-03-07 12:13    [W:4.076 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site