On Thu 2007-03-08 14:39:15, Zachary Amsden wrote:
> Ingo Molnar wrote:
> >* Zachary Amsden <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Ingo, either you or Thomas have vetoed every attempt we have made to
> >>make our code operate with clockevents. [...]
> >>
> >
> >this is news to me - do you
On Thu 2007-03-08 14:39:15, Zachary Amsden wrote:
Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
Ingo, either you or Thomas have vetoed every attempt we have made to
make our code operate with clockevents. [...]
this is news to me - do you have any proof of such a
Thomas Gleixner wrote:
> Once you are there, you are near the point where you created a virtual
> architecture, which could run on any real architecture which gets
> supported by a hypervisor backend.
>
> I'd love that :)
>
Sure. But not even hypervisors. Once we sort out pv_ops's SMP
[ I don't really want to be involved too much in this particular
discussion, but I'll pipe up quickly anyway.. ]
On Thu, 8 Mar 2007, Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
> > For APICs, we have two operations - APICRead and APICWrite. It is
> > nice and clean, and plugs in very
On Thu, 2007-03-08 at 15:55 -0800, Zachary Amsden wrote:
> Jeremy Fitzhardinge wrote:
> > No, but I'm not prejudiced against virtual hardware. If we have a piece
> > of code that thinks its talking to an apic, then I think its OK to use
> > that code whether its a real apic or a virtual one, _so
On Thu, 2007-03-08 at 15:55 -0800, Zachary Amsden wrote:
>
> We just don't drive the local timer interrupts through the APIC, we make
> hypercalls to schedule local timer alarms. Which is something we must
> do for UP kernels as well, which use the PIT / PIC. So there is a need
> for having
Zachary Amsden wrote:
> For APICs, we have two operations - APICRead and APICWrite. It is
> nice and clean, and plugs in very easily to the APIC accessors
> available in Linux.
>
> Is this not clean?
Sure, that's clean, From that perspective the apic is a bunch of
registers backed by a state
On Thu, 2007-03-08 at 15:39 -0800, Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
> > - /One/ _intelligent_ higher-level virtualization API/ABI. Xen's API is
> >quite advanced on this front.
>
> At last! Some love!
>
> The Xen approach has always been to prefer high-level interfaces over
Jeremy Fitzhardinge wrote:
No, but I'm not prejudiced against virtual hardware. If we have a piece
of code that thinks its talking to an apic, then I think its OK to use
that code whether its a real apic or a virtual one, _so long as its
being used in a way that's consistent with its intended
Ingo Molnar wrote:
> - /One/ _intelligent_ higher-level virtualization API/ABI. Xen's API is
>quite advanced on this front.
At last! Some love!
The Xen approach has always been to prefer high-level interfaces over
lower-level ones, so that guests can meaningfully participate in their
own
Ingo Molnar wrote:
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
[...] So it is a little late to tell us - "redesign your hypervisor,
or else.."
is this how long the "paravirt_ops hides all the details and the VMI
hypervisor ABI will never hinder Linux" sham lasted? Now that your
Andi Kleen wrote:
At least in Linux we don't really work with deadlines; if there
are issues they need to be fixed even if it takes longer. I don't
expect the version in .21 to be really usable anyways; it is clearly
still in development.
It was working, and I expect to have it working
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
> [...] So it is a little late to tell us - "redesign your hypervisor,
> or else.."
is this how long the "paravirt_ops hides all the details and the VMI
hypervisor ABI will never hinder Linux" sham lasted? Now that your stuff
is upstream barely 2
Ingo Molnar wrote:
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
Ingo, either you or Thomas have vetoed every attempt we have made to
make our code operate with clockevents. [...]
this is news to me - do you have any proof of such a veto?
Yes, your refusal to discuss any technical
Ingo Molnar wrote:
[...] And apparently the VMI version is the same, just with some short
cuts. Are you just worried about the ->apic_write() hooks or about
something else too?
i'm worried about those "shot cuts" (which in essence create software
variants of silicon), the hooks, the
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
> Ingo, either you or Thomas have vetoed every attempt we have made to
> make our code operate with clockevents. [...]
this is news to me - do you have any proof of such a veto?
Ingo
-
To unsubscribe from this list: send the line
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
We faithfully emulate lapic, io_apic, the pit, pic, and a normal
interrupt subsystem.
Can you not just use the apic clock driver directly then? Do you need
to do anything special?
The apic clock driver is going to program the
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > what we do _NOT_ want is some mixture of 'simplified' and
> > 'hardwired' native hardware access mixed with hypercalls that
> > somehow ends up creating a Frankenstein mixture of 'virtual
> > silicon', is specified nowhere else but in VMWare's
Ingo Molnar wrote:
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
When we're about two weeks away from a product release and you are
threatening to unmerge or block our code because we didn't create an
abstract interrupt controller, we re-used the APIC and IO-APIC, this
is uber rocket
> what we do _NOT_ want is some mixture of 'simplified' and 'hardwired'
> native hardware access mixed with hypercalls that somehow ends up
> creating a Frankenstein mixture of 'virtual silicon', is specified
> nowhere else but in VMWare's proprietary hypervisor source code that we
> have no
On Thursday 08 March 2007 21:46, Zachary Amsden wrote:
> Thomas Gleixner wrote:
> > On Thu, 2007-03-08 at 02:06 -0800, Zachary Amsden wrote:
> >
> The correct solution here is to properly separate the APIC, SMP, and
> timer code so the logic of it which we want to reuse is separated
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Zachary Amsden wrote:
> > We faithfully emulate lapic, io_apic, the pit, pic, and a normal
> > interrupt subsystem.
>
> Can you not just use the apic clock driver directly then? Do you need
> to do anything special?
exactly. There are only
Zachary Amsden wrote:
> We faithfully emulate lapic, io_apic, the pit, pic, and a normal
> interrupt subsystem.
Can you not just use the apic clock driver directly then? Do you need
to do anything special?
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
> When we're about two weeks away from a product release and you are
> threatening to unmerge or block our code because we didn't create an
> abstract interrupt controller, we re-used the APIC and IO-APIC, this
> is uber rocket science. [...]
see
Thomas Gleixner wrote:
On Thu, 2007-03-08 at 02:06 -0800, Zachary Amsden wrote:
The correct solution here is to properly separate the APIC, SMP, and
timer code so the logic of it which we want to reuse is separated from
the hardware dependence. Clock events and clocksources take care of
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> Our code is in the tree now, and any attempts to break it using such
> justifications as easing maintenance for kernel developers in future
> releases are flat out false and improper.
That's not quite accurate. This is what Ingo was complaining
On Thu, 2007-03-08 at 02:06 -0800, Zachary Amsden wrote:
> >> The correct solution here is to properly separate the APIC, SMP, and
> >> timer code so the logic of it which we want to reuse is separated from
> >> the hardware dependence. Clock events and clocksources take care of
> >> most of
Ingo Molnar wrote:
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
The correct solution here is to properly separate the APIC, SMP, and
timer code so the logic of it which we want to reuse is separated from
the hardware dependence. Clock events and clocksources take care of
most of the timer
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
> The correct solution here is to properly separate the APIC, SMP, and
> timer code so the logic of it which we want to reuse is separated from
> the hardware dependence. Clock events and clocksources take care of
> most of the timer issues, but
* Zachary Amsden [EMAIL PROTECTED] wrote:
When we're about two weeks away from a product release and you are
threatening to unmerge or block our code because we didn't create an
abstract interrupt controller, we re-used the APIC and IO-APIC, this
is uber rocket science. [...]
see my mail
Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
When we're about two weeks away from a product release and you are
threatening to unmerge or block our code because we didn't create an
abstract interrupt controller, we re-used the APIC and IO-APIC, this
is uber rocket science.
* Andi Kleen [EMAIL PROTECTED] wrote:
what we do _NOT_ want is some mixture of 'simplified' and
'hardwired' native hardware access mixed with hypercalls that
somehow ends up creating a Frankenstein mixture of 'virtual
silicon', is specified nowhere else but in VMWare's proprietary
* Zachary Amsden [EMAIL PROTECTED] wrote:
Ingo, either you or Thomas have vetoed every attempt we have made to
make our code operate with clockevents. [...]
this is news to me - do you have any proof of such a veto?
Ingo
-
To unsubscribe from this list: send the line unsubscribe
Ingo Molnar wrote:
[...] And apparently the VMI version is the same, just with some short
cuts. Are you just worried about the -apic_write() hooks or about
something else too?
i'm worried about those shot cuts (which in essence create software
variants of silicon), the hooks, the
Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
Ingo, either you or Thomas have vetoed every attempt we have made to
make our code operate with clockevents. [...]
this is news to me - do you have any proof of such a veto?
Yes, your refusal to discuss any technical
* Zachary Amsden [EMAIL PROTECTED] wrote:
[...] So it is a little late to tell us - redesign your hypervisor,
or else..
is this how long the paravirt_ops hides all the details and the VMI
hypervisor ABI will never hinder Linux sham lasted? Now that your stuff
is upstream barely 2 weeks
Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
[...] So it is a little late to tell us - redesign your hypervisor,
or else..
is this how long the paravirt_ops hides all the details and the VMI
hypervisor ABI will never hinder Linux sham lasted? Now that your stuff
is
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
Our code is in the tree now, and any attempts to break it using such
justifications as easing maintenance for kernel developers in future
releases are flat out false and improper.
That's not quite accurate. This is what Ingo was complaining about
Thomas Gleixner wrote:
On Thu, 2007-03-08 at 02:06 -0800, Zachary Amsden wrote:
The correct solution here is to properly separate the APIC, SMP, and
timer code so the logic of it which we want to reuse is separated from
the hardware dependence. Clock events and clocksources take care of
Zachary Amsden wrote:
We faithfully emulate lapic, io_apic, the pit, pic, and a normal
interrupt subsystem.
Can you not just use the apic clock driver directly then? Do you need
to do anything special?
J
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Zachary Amsden wrote:
We faithfully emulate lapic, io_apic, the pit, pic, and a normal
interrupt subsystem.
Can you not just use the apic clock driver directly then? Do you need
to do anything special?
exactly. There are only two
On Thursday 08 March 2007 21:46, Zachary Amsden wrote:
Thomas Gleixner wrote:
On Thu, 2007-03-08 at 02:06 -0800, Zachary Amsden wrote:
The correct solution here is to properly separate the APIC, SMP, and
timer code so the logic of it which we want to reuse is separated from
the
what we do _NOT_ want is some mixture of 'simplified' and 'hardwired'
native hardware access mixed with hypercalls that somehow ends up
creating a Frankenstein mixture of 'virtual silicon', is specified
nowhere else but in VMWare's proprietary hypervisor source code that we
have no way
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
We faithfully emulate lapic, io_apic, the pit, pic, and a normal
interrupt subsystem.
Can you not just use the apic clock driver directly then? Do you need
to do anything special?
The apic clock driver is going to program the
Andi Kleen wrote:
At least in Linux we don't really work with deadlines; if there
are issues they need to be fixed even if it takes longer. I don't
expect the version in .21 to be really usable anyways; it is clearly
still in development.
It was working, and I expect to have it working
Ingo Molnar wrote:
- /One/ _intelligent_ higher-level virtualization API/ABI. Xen's API is
quite advanced on this front.
At last! Some love!
The Xen approach has always been to prefer high-level interfaces over
lower-level ones, so that guests can meaningfully participate in their
own
Jeremy Fitzhardinge wrote:
No, but I'm not prejudiced against virtual hardware. If we have a piece
of code that thinks its talking to an apic, then I think its OK to use
that code whether its a real apic or a virtual one, _so long as its
being used in a way that's consistent with its intended
On Thu, 2007-03-08 at 15:39 -0800, Jeremy Fitzhardinge wrote:
Ingo Molnar wrote:
- /One/ _intelligent_ higher-level virtualization API/ABI. Xen's API is
quite advanced on this front.
At last! Some love!
The Xen approach has always been to prefer high-level interfaces over
Zachary Amsden wrote:
For APICs, we have two operations - APICRead and APICWrite. It is
nice and clean, and plugs in very easily to the APIC accessors
available in Linux.
Is this not clean?
Sure, that's clean, From that perspective the apic is a bunch of
registers backed by a state machine
On Thu, 2007-03-08 at 15:55 -0800, Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
No, but I'm not prejudiced against virtual hardware. If we have a piece
of code that thinks its talking to an apic, then I think its OK to use
that code whether its a real apic or a virtual one, _so long as
On Thu, 2007-03-08 at 15:55 -0800, Zachary Amsden wrote:
We just don't drive the local timer interrupts through the APIC, we make
hypercalls to schedule local timer alarms. Which is something we must
do for UP kernels as well, which use the PIT / PIC. So there is a need
for having
[ I don't really want to be involved too much in this particular
discussion, but I'll pipe up quickly anyway.. ]
On Thu, 8 Mar 2007, Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
For APICs, we have two operations - APICRead and APICWrite. It is
nice and clean, and plugs in very
Thomas Gleixner wrote:
Once you are there, you are near the point where you created a virtual
architecture, which could run on any real architecture which gets
supported by a hypervisor backend.
I'd love that :)
Sure. But not even hypervisors. Once we sort out pv_ops's SMP support,
it
* Zachary Amsden [EMAIL PROTECTED] wrote:
The correct solution here is to properly separate the APIC, SMP, and
timer code so the logic of it which we want to reuse is separated from
the hardware dependence. Clock events and clocksources take care of
most of the timer issues, but there is
Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
The correct solution here is to properly separate the APIC, SMP, and
timer code so the logic of it which we want to reuse is separated from
the hardware dependence. Clock events and clocksources take care of
most of the timer
On Thu, 2007-03-08 at 02:06 -0800, Zachary Amsden wrote:
The correct solution here is to properly separate the APIC, SMP, and
timer code so the logic of it which we want to reuse is separated from
the hardware dependence. Clock events and clocksources take care of
most of the timer
56 matches
Mail list logo
