>
> Maybe hooking into genapic is the right way to mop up all the uses of
> send_IPI and its variants.
It is. More hooks in this are wouldn't be appreciated.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Maybe hooking into genapic is the right way to mop up all the uses of
> send_IPI and its variants. But from a quick grep it doesn't look like
> they get called from too many places... Most of the callers seem to be
> in arch/i386/kernek/smp.c,
Chris Wright wrote:
> * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
>
>> Maybe hooking into genapic is the right way to mop up all the uses of
>> send_IPI and its variants. But from a quick grep it doesn't look like
>> they get called from too many places... Most of the callers seem to be
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> I guess by "rest of the kernel" you mean other stuff in arch/i386. Yes,
> that's a concern, but maybe we can tease it apart in a sensible way.
Yes, that's exactly what I'm saying. Same with above (the native stuff), since
we don't want a bunch
Chris Wright wrote:
> * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
>
>> I guess by "rest of the kernel" you mean other stuff in arch/i386. Yes,
>> that's a concern, but maybe we can tease it apart in a sensible way.
>>
>
> Yes, that's exactly what I'm saying. Same with above (the
Chris Wright wrote:
> * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
>
>> Chris Wright wrote:
>>
>>> I agree with that, but I think that's esp. for things like create and launch
>>> new vcpu. The IPI bit I'm not as clear on, nor running this all on native
>>> as well.
>>>
>>>
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > * Daniel Arai ([EMAIL PROTECTED]) wrote:
> >
> >> There's no good way to override __send_IPI_shortcut. I suppose we could
> >> add
> >> paravirt ops for __send_IPI_shortcut and every other op that touches the
> >>
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > I agree with that, but I think that's esp. for things like create and launch
> > new vcpu. The IPI bit I'm not as clear on, nor running this all on native
> > as well.
> >
>
> Well, native would fall back to using the
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > While that's basically what we did in Xen, it would make more sense
> > to build it into genapic which would give us one common abstraction
> > to base from. We should avoid adding pv_ops when existing
> > infrastructure exists.
>
> I was
Chris Wright wrote:
> I agree with that, but I think that's esp. for things like create and launch
> new vcpu. The IPI bit I'm not as clear on, nor running this all on native
> as well.
>
Well, native would fall back to using the existing arch/i386 versions of
those functions, so that's
Chris Wright wrote:
> * Daniel Arai ([EMAIL PROTECTED]) wrote:
>
>> There's no good way to override __send_IPI_shortcut. I suppose we could add
>> paravirt ops for __send_IPI_shortcut and every other op that touches the
>> APIC.
>>
>
> While that's basically what we did in Xen, it
* Daniel Arai ([EMAIL PROTECTED]) wrote:
> Chris, would you like to work together on this? I don't know what Xen's
> requirements are for the APIC interface. Do you think we could come up
> with something that would fit both of our needs, and maybe also be usable
> for some of the
* Chris Wright <[EMAIL PROTECTED]> wrote:
> > Chris, would you like to work together on this? I don't know what
> > Xen's requirements are for the APIC interface. Do you think we
> > could come up with something that would fit both of our needs, and
> > maybe also be usable for some of the
Chris Wright wrote:
* Daniel Arai ([EMAIL PROTECTED]) wrote:
There's no good way to override __send_IPI_shortcut. I suppose we could add
paravirt ops for __send_IPI_shortcut and every other op that touches the APIC.
While that's basically what we did in Xen, it would make more sense to
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> s/do/will (smpboot.c)
Well the current Xen mechanism rather dodges all of that (for bits like
IPI apicid).
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
* Daniel Arai ([EMAIL PROTECTED]) wrote:
> There's no good way to override __send_IPI_shortcut. I suppose we could add
> paravirt ops for __send_IPI_shortcut and every other op that touches the
> APIC.
While that's basically what we did in Xen, it would make more sense to
build it into
On Thu, 2007-03-08 at 09:01 +0100, Ingo Molnar wrote:
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> > > Your implementation is almost the perfect prototype, if you move the
> > > 128 bit hackery into the hypervisor and hide it away from the kernel
> > > :)
> >
> > The point is to use
Ingo Molnar wrote:
> you are obsessed with avoiding a hypercall, but why? Granted it's slow
> especially on things like SVN/VMX, but it's not fundamentally slow. We
> definitely do not want to design our whole APIs and abstractions around
> the temporary notion that 'hypercalls are slow'.
On 8/3/07 08:01, "Ingo Molnar" <[EMAIL PROTECTED]> wrote:
> you are obsessed with avoiding a hypercall, but why? Granted it's slow
> especially on things like SVN/VMX, but it's not fundamentally slow. We
> definitely do not want to design our whole APIs and abstractions around
> the temporary
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > Your implementation is almost the perfect prototype, if you move the
> > 128 bit hackery into the hypervisor and hide it away from the kernel
> > :)
>
> The point is to use the tsc to avoid making any hypercalls, so dealing
> with the
Thomas Gleixner wrote:
On Wed, 2007-03-07 at 17:01 -0800, Daniel Arai wrote:
But more importantly, we want a kernel that can run both on native hardware and
in a paravirtualized environment. Linux doesn't really provide abstractions for
replacing the appropriate code. We tried to hook
* Daniel Arai ([EMAIL PROTECTED]) wrote:
There's no good way to override __send_IPI_shortcut. I suppose we could add
paravirt ops for __send_IPI_shortcut and every other op that touches the
APIC.
While that's basically what we did in Xen, it would make more sense to
build it into genapic
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
s/do/will (smpboot.c)
Well the current Xen mechanism rather dodges all of that (for bits like
IPI apicid).
thanks,
-chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Chris Wright wrote:
* Daniel Arai ([EMAIL PROTECTED]) wrote:
There's no good way to override __send_IPI_shortcut. I suppose we could add
paravirt ops for __send_IPI_shortcut and every other op that touches the APIC.
While that's basically what we did in Xen, it would make more sense to
* Chris Wright [EMAIL PROTECTED] wrote:
Chris, would you like to work together on this? I don't know what
Xen's requirements are for the APIC interface. Do you think we
could come up with something that would fit both of our needs, and
maybe also be usable for some of the
* Daniel Arai ([EMAIL PROTECTED]) wrote:
Chris, would you like to work together on this? I don't know what Xen's
requirements are for the APIC interface. Do you think we could come up
with something that would fit both of our needs, and maybe also be usable
for some of the
Chris Wright wrote:
* Daniel Arai ([EMAIL PROTECTED]) wrote:
There's no good way to override __send_IPI_shortcut. I suppose we could add
paravirt ops for __send_IPI_shortcut and every other op that touches the
APIC.
While that's basically what we did in Xen, it would make more
Chris Wright wrote:
I agree with that, but I think that's esp. for things like create and launch
new vcpu. The IPI bit I'm not as clear on, nor running this all on native
as well.
Well, native would fall back to using the existing arch/i386 versions of
those functions, so that's
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
While that's basically what we did in Xen, it would make more sense
to build it into genapic which would give us one common abstraction
to base from. We should avoid adding pv_ops when existing
infrastructure exists.
I was looking at
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Chris Wright wrote:
* Daniel Arai ([EMAIL PROTECTED]) wrote:
There's no good way to override __send_IPI_shortcut. I suppose we could
add
paravirt ops for __send_IPI_shortcut and every other op that touches the
APIC.
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Chris Wright wrote:
I agree with that, but I think that's esp. for things like create and launch
new vcpu. The IPI bit I'm not as clear on, nor running this all on native
as well.
Well, native would fall back to using the existing
Chris Wright wrote:
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Chris Wright wrote:
I agree with that, but I think that's esp. for things like create and launch
new vcpu. The IPI bit I'm not as clear on, nor running this all on native
as well.
Well, native would
Chris Wright wrote:
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
I guess by rest of the kernel you mean other stuff in arch/i386. Yes,
that's a concern, but maybe we can tease it apart in a sensible way.
Yes, that's exactly what I'm saying. Same with above (the native stuff),
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
I guess by rest of the kernel you mean other stuff in arch/i386. Yes,
that's a concern, but maybe we can tease it apart in a sensible way.
Yes, that's exactly what I'm saying. Same with above (the native stuff), since
we don't want a bunch of
Chris Wright wrote:
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Maybe hooking into genapic is the right way to mop up all the uses of
send_IPI and its variants. But from a quick grep it doesn't look like
they get called from too many places... Most of the callers seem to be
in
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Maybe hooking into genapic is the right way to mop up all the uses of
send_IPI and its variants. But from a quick grep it doesn't look like
they get called from too many places... Most of the callers seem to be
in arch/i386/kernek/smp.c, so
Maybe hooking into genapic is the right way to mop up all the uses of
send_IPI and its variants.
It is. More hooks in this are wouldn't be appreciated.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Thomas Gleixner wrote:
On Wed, 2007-03-07 at 17:01 -0800, Daniel Arai wrote:
But more importantly, we want a kernel that can run both on native hardware and
in a paravirtualized environment. Linux doesn't really provide abstractions for
replacing the appropriate code. We tried to hook
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Your implementation is almost the perfect prototype, if you move the
128 bit hackery into the hypervisor and hide it away from the kernel
:)
The point is to use the tsc to avoid making any hypercalls, so dealing
with the tsc-ns
On 8/3/07 08:01, Ingo Molnar [EMAIL PROTECTED] wrote:
you are obsessed with avoiding a hypercall, but why? Granted it's slow
especially on things like SVN/VMX, but it's not fundamentally slow. We
definitely do not want to design our whole APIs and abstractions around
the temporary notion that
Ingo Molnar wrote:
you are obsessed with avoiding a hypercall, but why? Granted it's slow
especially on things like SVN/VMX, but it's not fundamentally slow. We
definitely do not want to design our whole APIs and abstractions around
the temporary notion that 'hypercalls are slow'.
Sure.
On Thu, 2007-03-08 at 09:01 +0100, Ingo Molnar wrote:
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Your implementation is almost the perfect prototype, if you move the
128 bit hackery into the hypervisor and hide it away from the kernel
:)
The point is to use the tsc to avoid
On Wed, 2007-03-07 at 17:01 -0800, Daniel Arai wrote:
> Thomas Gleixner wrote:
>
> > You managed to avoid the usage of other code (i.e. PIT / HPET) already,
> > so why is it sooo desireable to emulate apics instead of substituting it
> > by a small and sane replacement ? Just because you happen
On Wed, 2007-03-07 at 17:23 -0800, Jeremy Fitzhardinge wrote:
> Daniel Arai wrote:
> > But more importantly, we want a kernel that can run both on native hardware
> > and
> > in a paravirtualized environment. Linux doesn't really provide
> > abstractions for
> > replacing the appropriate
Daniel Arai wrote:
> But more importantly, we want a kernel that can run both on native hardware
> and
> in a paravirtualized environment. Linux doesn't really provide abstractions
> for
> replacing the appropriate code. We tried to hook into the source code at a
> level that seemed
Thomas Gleixner wrote:
You managed to avoid the usage of other code (i.e. PIT / HPET) already,
so why is it sooo desireable to emulate apics instead of substituting it
by a small and sane replacement ? Just because you happen to have an
LAPIC emulator ? That's no reason to wire yourself into
Thomas Gleixner wrote:
> Sigh. The cut zero hairball is already in mainline. :(
>
Yes, there were a couple of unfortunate patches in that series, but they
got fast-tracked in with the promise they would get fixed asap.
> Sure. If the clockevent API is changed, then the users get fixed. This
>
On Wed, 2007-03-07 at 15:33 -0800, Jeremy Fitzhardinge wrote:
> > On the other hand we yet see things like:
> >
> > /* We use normal irq0 handler on cpu0. */
> > time_init_hook();
> >
> > Which is just reaching into the kernel code directly and does not handle
> > the clock event
Dan Hecht wrote:
> On 03/07/2007 03:33 PM, Jeremy Fitzhardinge wrote:
>> I know the vmi time code has coloured your view here, but I surely hope
>> it can be got into a better state before posting. I'm biased of course,
>> but I would rather hope that all these drivers we're talking about will
>>
On Wed, 2007-03-07 at 15:25 -0800, Zachary Amsden wrote:
> > Looking at vmitimer.c and the number of hardcoded assumptions are
> > telling me, that we are heading in exactly the opposite direction.
> >
>
> No, VMI timer is unique because for SMP, it is based on the APIC. On
> i386, SMP is
On 03/07/2007 03:33 PM, Jeremy Fitzhardinge wrote:
I know the vmi time code has coloured your view here, but I surely hope
it can be got into a better state before posting. I'm biased of course,
but I would rather hope that all these drivers we're talking about will
be as stylistically clean as
> Yep, the tsc has myriad problems; for Xen its the best of a bad lot.
> Unfortunately in 10 years no clearly better alternative has appeared;
> maybe in 10 years there will be one. It might even be the tsc.
TSC is essentially unusable for any kind of time related work. And I'd
disagree about
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Xen needs pieces of it too, but very select pieces for SMP boot.
We do? Send the SMP Xen code over, because I don't have it here.
s/do/will (smpboot.c)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Zachary Amsden wrote:
> Xen needs pieces of it too, but very select pieces for SMP boot.
We do? Send the SMP Xen code over, because I don't have it here.
Thanks,
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Thomas Gleixner wrote:
> Still there is a difference between using existing kernel interfaces and
> abusing them in a way which makes modifications to the core kernel code
> hard and unmaintainable. See below.
>
I completely agree. "Using the kernel interfaces" doesn't mean "this
random hack
Thomas Gleixner wrote:
On the other hand we yet see things like:
/* We use normal irq0 handler on cpu0. */
time_init_hook();
Which is just reaching into the kernel code directly and does not handle
the clock event interrupt self contained. clockevents is not bound to
IRQ0 and
On Wed, 2007-03-07 at 14:05 -0800, Jeremy Fitzhardinge wrote:
> Thomas Gleixner wrote:
> > This is tinkering of the best. My understanding of the paravirt
> > discussion at Kernel Summit was, that paravirt ops are exactly there to
> > prevent the above random hackery in the kernel and to allow
On 03/07/2007 02:31 PM, Thomas Gleixner wrote:
Please make these things self contained and not relying on whatever
time_init_hook() contains.
Fixing up the code to do this now
thanks,
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Wed, 2007-03-07 at 14:17 -0800, Zachary Amsden wrote:
> Thomas Gleixner wrote:
> > Simply because you _ABUSE_ timer_init_hook() to set it up. Keep it self
> > contained and do not impose restrictions on the kernel core code, which
> > we have to maintain.
> >
>
> But time_init_hook is
Thomas Gleixner wrote:
Simply because you _ABUSE_ timer_init_hook() to set it up. Keep it self
contained and do not impose restrictions on the kernel core code, which
we have to maintain.
But time_init_hook is supposed to be abused. That is its purpose - to
be a hook for different time
On Wed, 2007-03-07 at 13:34 -0800, Dan Hecht wrote:
> On 03/07/2007 01:40 PM, Thomas Gleixner wrote:
> > On Wed, 2007-03-07 at 13:07 -0800, Jeremy Fitzhardinge wrote:
> > That would certainly be ideal. We'll look at the xen, vmi, lguest and
> >> kvm paravirtualized time models and see how much
Thomas Gleixner wrote:
> This is tinkering of the best. My understanding of the paravirt
> discussion at Kernel Summit was, that paravirt ops are exactly there to
> prevent the above random hackery in the kernel and to allow _ALL_
> hypervisors to interact via a sane interface inside of the
On Wed, 2007-03-07 at 13:42 -0800, Dan Hecht wrote:
> On 03/07/2007 12:40 PM, Thomas Gleixner wrote:
> > Real hardware copes well with relative deltas for the events, even when
> > it is match register based. I thought long about the support for
> > absolute expiry values in cycles and decided
On 03/07/2007 12:40 PM, Thomas Gleixner wrote:
Real hardware copes well with relative deltas for the events, even when
it is match register based. I thought long about the support for
absolute expiry values in cycles and decided against them to avoid that
math hackery, which you folks now
On 03/07/2007 01:40 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 13:07 -0800, Jeremy Fitzhardinge wrote:
That would certainly be ideal. We'll look at the xen, vmi, lguest and
kvm paravirtualized time models and see how much they really have in
common. I'm a bit curious about how vmi's
On 03/07/2007 01:21 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 11:49 -0800, Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's ours
for reference (please excuse any formating issues); it's also lean.
We'll send out a proper patch later after some more
On Wed, 2007-03-07 at 13:07 -0800, Jeremy Fitzhardinge wrote:
> Thomas Gleixner wrote:
> > I tend to disagree. The clockevents infrastructure was designed to cope
> > with the existing mess of real hardware. The discussion over the last
> > days exposed me to even more exotic designs than the
On 03/07/2007 01:19 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 13:02 -0800, Dan Hecht wrote:
On 03/07/2007 12:57 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 12:11 -0800, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
On Wed, 2007-03-07 at 11:49 -0800, Dan Hecht wrote:
> Jeremy, I saw you sent out the Xen version earlier, thanks. Here's ours
> for reference (please excuse any formating issues); it's also lean.
> We'll send out a proper patch later after some more testing:
Ah. Bitching loud enough speeds
On Wed, 2007-03-07 at 13:02 -0800, Dan Hecht wrote:
> On 03/07/2007 12:57 PM, Thomas Gleixner wrote:
> > On Wed, 2007-03-07 at 12:11 -0800, Jeremy Fitzhardinge wrote:
> >> Dan Hecht wrote:
> >>> Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
> >>> ours for reference (please
On Wed, 2007-03-07 at 12:49 -0800, Dan Hecht wrote:
> On 03/07/2007 12:11 PM, Jeremy Fitzhardinge wrote:
> > Dan Hecht wrote:
> >> Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
> >> ours for reference (please excuse any formating issues); it's also
> >> lean. We'll send out a
Thomas Gleixner wrote:
> I tend to disagree. The clockevents infrastructure was designed to cope
> with the existing mess of real hardware. The discussion over the last
> days exposed me to even more exotic designs than the hardware vendors
> were able to deliver until now.
>
It's a different
Dan Hecht wrote:
> Are you saying you would prefer we create our own irq handler
> something like this rather than using the standard i386 handlers?
>
> irqreturn_t vmi_timer_interrupt(int irq, void *dev_id)
> {
>local_event->event_handler(local_event);
>return IRQ_HANDLED;
> }
>
> ??
On 03/07/2007 12:57 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 12:11 -0800, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
ours for reference (please excuse any formating issues); it's also
lean. We'll send out a proper
On 03/07/2007 12:11 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
ours for reference (please excuse any formating issues); it's also
lean. We'll send out a proper patch later after some more testing:
So the interrupt side
On Wed, 2007-03-07 at 12:11 -0800, Jeremy Fitzhardinge wrote:
> Dan Hecht wrote:
> > Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
> > ours for reference (please excuse any formating issues); it's also
> > lean. We'll send out a proper patch later after some more testing:
>
On Wed, 2007-03-07 at 09:41 -0800, Jeremy Fitzhardinge wrote:
> Other hypervisors may take other approaches, depending on what the real
> underlying hardware is and the real requirements. One could imagine a
> hypervisor exposing an hpet mapping, for example, or just having some
> kind of
Dan Hecht wrote:
> Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
> ours for reference (please excuse any formating issues); it's also
> lean. We'll send out a proper patch later after some more testing:
So the interrupt side of the clockevent comes through the virtual apic?
On 03/07/2007 11:05 AM, Jeremy Fitzhardinge wrote:
James Morris wrote:
It seems to me that it could be useful to have a library of common virtual
time code (entirely separate from pv_ops), to avoid re-implementing some
apparently common requirements, such as: handling TSC frequency changes,
James Morris wrote:
> It seems to me that it could be useful to have a library of common virtual
> time code (entirely separate from pv_ops), to avoid re-implementing some
> apparently common requirements, such as: handling TSC frequency changes,
> stolen time accounting, synthetic programmable
On Wed, 2007-03-07 at 13:11 -0500, James Morris wrote:
> On Wed, 7 Mar 2007, Jeremy Fitzhardinge wrote:
>
> > I was very pleased when I saw the clocksource/event mechanisms go into
> > the kernel because it means different hypervisors can have a clock*
> > implementation to match their own
On Wed, 2007-03-07 at 10:28 -0800, Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
> > /For you/ it's certainly no big deal, you dont have to fix it up and you
> > dont have to keep it flexible ;)
> >
>
> How flexible does it need to be? Its a simple time source and event
> driver. How
Ingo Molnar wrote:
> ugh. Please take it from me: i've watched the Linux time code walk its
> long, rocky 10+ years road. One of the first mistakes was when we made
> the TSC the center of the i386-time universe. (incidentally, it was me
> who did the first steps of that, as a rookie kernel
Ingo Molnar wrote:
> /For you/ it's certainly no big deal, you dont have to fix it up and you
> dont have to keep it flexible ;)
>
How flexible does it need to be? Its a simple time source and event
driver. How flexible does the pit driver need to be? It's just a small
leaf node hanging
On Wed, 7 Mar 2007, Jeremy Fitzhardinge wrote:
> I was very pleased when I saw the clocksource/event mechanisms go into
> the kernel because it means different hypervisors can have a clock*
> implementation to match their own particular time model/interface
> without having to clutter up the
On Wed, 7 Mar 2007, Ingo Molnar wrote:
>
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> > Xen, for example, uses the tsc as the principle timebase in the
> > hypervisor interface. [...]
>
> ugh. Please take it from me: i've watched the Linux time code walk its
> long, rocky 10+ years
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> I don't think having a clock implementation for each hypervisor is
> such a big deal. The Xen one, for example, is 300 lines of
> straightforward code.
/For you/ it's certainly no big deal, you dont have to fix it up and you
dont have to
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Xen, for example, uses the tsc as the principle timebase in the
> hypervisor interface. [...]
ugh. Please take it from me: i've watched the Linux time code walk its
long, rocky 10+ years road. One of the first mistakes was when we made
the
Thomas Gleixner wrote:
> That's a pure academic exercise. When we are at the point where
> nanoseconds are to coarse - sometimes after we both retired - the
> internal resolution will be femtoseconds or whatever fits.
>
> Again: paravirt should use a common infrastructure for this. Virtual
>
On Tue, 2007-03-06 at 18:08 -0800, Dan Hecht wrote:
> > IMO the paravirt interfaces should use nanoseconds anyway for both
> > readout and next event programming. That way the conversion is done in
> > the hypervisor once and the clocksources and clockevents are simple and
> > unified (except for
On Tue, 2007-03-06 at 18:08 -0800, Dan Hecht wrote:
IMO the paravirt interfaces should use nanoseconds anyway for both
readout and next event programming. That way the conversion is done in
the hypervisor once and the clocksources and clockevents are simple and
unified (except for the
Thomas Gleixner wrote:
That's a pure academic exercise. When we are at the point where
nanoseconds are to coarse - sometimes after we both retired - the
internal resolution will be femtoseconds or whatever fits.
Again: paravirt should use a common infrastructure for this. Virtual
clocksource
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Xen, for example, uses the tsc as the principle timebase in the
hypervisor interface. [...]
ugh. Please take it from me: i've watched the Linux time code walk its
long, rocky 10+ years road. One of the first mistakes was when we made
the TSC
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
I don't think having a clock implementation for each hypervisor is
such a big deal. The Xen one, for example, is 300 lines of
straightforward code.
/For you/ it's certainly no big deal, you dont have to fix it up and you
dont have to keep it
On Wed, 7 Mar 2007, Ingo Molnar wrote:
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Xen, for example, uses the tsc as the principle timebase in the
hypervisor interface. [...]
ugh. Please take it from me: i've watched the Linux time code walk its
long, rocky 10+ years road. One of
On Wed, 7 Mar 2007, Jeremy Fitzhardinge wrote:
I was very pleased when I saw the clocksource/event mechanisms go into
the kernel because it means different hypervisors can have a clock*
implementation to match their own particular time model/interface
without having to clutter up the pv_ops
Ingo Molnar wrote:
/For you/ it's certainly no big deal, you dont have to fix it up and you
dont have to keep it flexible ;)
How flexible does it need to be? Its a simple time source and event
driver. How flexible does the pit driver need to be? It's just a small
leaf node hanging off a
Ingo Molnar wrote:
ugh. Please take it from me: i've watched the Linux time code walk its
long, rocky 10+ years road. One of the first mistakes was when we made
the TSC the center of the i386-time universe. (incidentally, it was me
who did the first steps of that, as a rookie kernel hacker)
On Wed, 2007-03-07 at 10:28 -0800, Jeremy Fitzhardinge wrote:
Ingo Molnar wrote:
/For you/ it's certainly no big deal, you dont have to fix it up and you
dont have to keep it flexible ;)
How flexible does it need to be? Its a simple time source and event
driver. How flexible does
On Wed, 2007-03-07 at 13:11 -0500, James Morris wrote:
On Wed, 7 Mar 2007, Jeremy Fitzhardinge wrote:
I was very pleased when I saw the clocksource/event mechanisms go into
the kernel because it means different hypervisors can have a clock*
implementation to match their own particular
1 - 100 of 172 matches
Mail list logo
