On Mon, Jan 29, 2007 at 09:09:14AM +1100, Benjamin Herrenschmidt wrote:
>
> If we followed that "only do incrementental changes" rule all the time,
> imagine in what state would be our USB stack today since we couldn't
> have dropped in Linus replacement one ...
Bad example, that is not what
On Mon, Jan 29, 2007 at 09:09:14AM +1100, Benjamin Herrenschmidt wrote:
If we followed that only do incrementental changes rule all the time,
imagine in what state would be our USB stack today since we couldn't
have dropped in Linus replacement one ...
Bad example, that is not what happened
I just got an answer from the hypervisor architects. It turns out
that the hardware _does_ prevent the device from sending MSI messages
to another partition. The OS _can_ write whatever it likes to the MSI
address and data registers. It can potentially lose interrupts (or, I
expect, get the
I just got an answer from the hypervisor architects. It turns out
that the hardware _does_ prevent the device from sending MSI messages
to another partition. The OS _can_ write whatever it likes to the MSI
address and data registers. It can potentially lose interrupts (or, I
expect, get the
> It's possible that the device can do MSI(X), but that using MSI(X)
> requires other platform resources (e.g. interrupt source numbers) and
> there are none free. I believe the platform guarantees a minimum
> number of MSI(X) interrupts per function, but a pci_enable_msix() call
> may not be
Michael Ellerman writes:
> You can read config space, but it's not clear to me if the HV is allowed
> to filter it and hide things. It's also possible that the device
It appears that the HV does not prevent us from reading or writing any
config space registers for functions that are assigned to
Benjamin Herrenschmidt writes:
> > I'd hate to hit a different Hypervisor that did something close but
> > not quite the same and have the code fail then. So definitely
> > avoiding touching pci config space at all in the calls seems to make a
> > lot of sense. This includes avoiding
> You can read config space, but it's not clear to me if the HV is allowed
> to filter it and hide things.
I've seen it do it for example with EADS bridges. I haven't seen doing
it with devices (other than hiding entire functions) but I wouldn't
exclude it...
> It's also possible that the
> This is the most straight forward and handles machines with really
> weird msi setups, so I lean in this direction.
>
> The question is there anything at all we can do generically?
>
> I can't see a case where ppc_md would not wind up with the hooks
> that decide if it is a hypervisor or not.
On Mon, 2007-01-29 at 02:03 -0700, Eric W. Biederman wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > On Sun, 2007-01-28 at 21:25 -0800, David Miller wrote:
> >> From: [EMAIL PROTECTED] (Eric W. Biederman)
> >> Date: Sun, 28 Jan 2007 22:18:59 -0700
> >>
> >> > Regardless of my
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> On Sun, 2007-01-28 at 21:25 -0800, David Miller wrote:
>> From: [EMAIL PROTECTED] (Eric W. Biederman)
>> Date: Sun, 28 Jan 2007 22:18:59 -0700
>>
>> > Regardless of my opinion on the sanity of the hypervisor architects.
>> > I have not seen
>
> That is to make Eric's code itself cope with the HV case. I'm a bit at
> loss right now as how precisely to do it. I need to spend more time
> staring at the code after Eric latest patches rather than the patches
> themselves I suppose :-) (Eric, they don't apply out of the box on
> current
That is to make Eric's code itself cope with the HV case. I'm a bit at
loss right now as how precisely to do it. I need to spend more time
staring at the code after Eric latest patches rather than the patches
themselves I suppose :-) (Eric, they don't apply out of the box on
current git,
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
On Sun, 2007-01-28 at 21:25 -0800, David Miller wrote:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 22:18:59 -0700
Regardless of my opinion on the sanity of the hypervisor architects.
I have not seen anything that
On Mon, 2007-01-29 at 02:03 -0700, Eric W. Biederman wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
On Sun, 2007-01-28 at 21:25 -0800, David Miller wrote:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 22:18:59 -0700
Regardless of my opinion on the
This is the most straight forward and handles machines with really
weird msi setups, so I lean in this direction.
The question is there anything at all we can do generically?
I can't see a case where ppc_md would not wind up with the hooks
that decide if it is a hypervisor or not. Even
You can read config space, but it's not clear to me if the HV is allowed
to filter it and hide things.
I've seen it do it for example with EADS bridges. I haven't seen doing
it with devices (other than hiding entire functions) but I wouldn't
exclude it...
It's also possible that the device
Benjamin Herrenschmidt writes:
I'd hate to hit a different Hypervisor that did something close but
not quite the same and have the code fail then. So definitely
avoiding touching pci config space at all in the calls seems to make a
lot of sense. This includes avoiding
Michael Ellerman writes:
You can read config space, but it's not clear to me if the HV is allowed
to filter it and hide things. It's also possible that the device
It appears that the HV does not prevent us from reading or writing any
config space registers for functions that are assigned to
It's possible that the device can do MSI(X), but that using MSI(X)
requires other platform resources (e.g. interrupt source numbers) and
there are none free. I believe the platform guarantees a minimum
number of MSI(X) interrupts per function, but a pci_enable_msix() call
may not be able to
On Sun, 2007-01-28 at 21:25 -0800, David Miller wrote:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sun, 28 Jan 2007 22:18:59 -0700
>
> > Regardless of my opinion on the sanity of the hypervisor architects.
> > I have not seen anything that indicates it will be hard to support
> > the
David Miller <[EMAIL PROTECTED]> writes:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sun, 28 Jan 2007 22:18:59 -0700
>
>> Regardless of my opinion on the sanity of the hypervisor architects.
>> I have not seen anything that indicates it will be hard to support
>> the hypervisor doing
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 22:18:59 -0700
> Regardless of my opinion on the sanity of the hypervisor architects.
> I have not seen anything that indicates it will be hard to support
> the hypervisor doing everything or most of everything for us, so
> I see
David Miller <[EMAIL PROTECTED]> writes:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sun, 28 Jan 2007 16:26:44 -0700
>
>> Yes. In general the mainline linux kernel does not support certain
>> classes of stupidity. TCP offload engines, firmware drivers for
>> hardware we care about, a
> To be clear I see this as 2 distinct layers of code. enable/disable
> that talks directly to the hardware, and the helpers of enable/disable
> that allocate the irq. I base this on the fact that I only need the
> alloc/free when I am exclusively working with real hardware.
We need the
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 14:20:12 -0700
> I see people pushing ridiculous interfaces like the RTAS hypervisor
> interface at me, and saying we must support running firmware drivers
> in the msi code.
This is not what's going on.
The hypervisor does the
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun, 28 Jan 2007 15:47:24 -0500
> I think the high-level ops approach makes more sense. It's more future
> proof, in addition to covering all existing implementations.
I totally agree with this.
-
To unsubscribe from this list: send the line
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 16:26:44 -0700
> Yes. In general the mainline linux kernel does not support certain
> classes of stupidity. TCP offload engines, firmware drivers for
> hardware we care about, a fixed ABI to binary only modules, etc.
> It is the
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> .../... (enable/disable bits)
>
>> Which are either talking directly to the hardware, or are talking
>> to the hypervisor, which is using hardware isolation so it is safe to
>> talk directly to the hardware but isn't leting us? If we could
Jeff Garzik <[EMAIL PROTECTED]> writes:
> I think the high-level ops approach makes more sense. It's more future proof,
> in addition to covering all existing implementations.
To be precise in Michaels implementation one of the parameters passed is
a type parameter so that the architecture has
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>> The other big change is that I added a field to irq_desc to point
>> at the msi_desc. This removes the conflicts with the existing pointer
>> fields and makes the irq -> msi_desc mapping useable outside of msi.c
>
> I'm not even sure we would
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> I'm not arguing against an operations based approach. I'm arguing for
> simple obviously correct steps, and not throwing the baby out with the
> bath water.
>
> My patches should be a precursor to an operations based approach
> because they
Jeff Garzik <[EMAIL PROTECTED]> writes:
> Benjamin Herrenschmidt wrote:
>>> The only architecture problem that isn't solvable in this context is
>>> the problem of supporting the crazy hypervisor on the ppc RTAS, which
>>> asks us to drive the hardware but does not give us access to the
>>>
Benjamin Herrenschmidt wrote:
The only architecture problem that isn't solvable in this context is
the problem of supporting the crazy hypervisor on the ppc RTAS, which
asks us to drive the hardware but does not give us access to the
hardware registers.
So you are saying that we should use
> The other big change is that I added a field to irq_desc to point
> at the msi_desc. This removes the conflicts with the existing pointer
> fields and makes the irq -> msi_desc mapping useable outside of msi.c
I'm not even sure we would have needed that with Michael's mecanism in
fact. One
This patchset is against gregkh-pci but except for the context around
msi_lookup_irq being completely different it applies cleanly to 2.6.20-rc6
as well.
When I first looked at this problem I thought no big deal it will one
or two simple patches and that is it.
When I looked more closely I
This patchset is against gregkh-pci but except for the context around
msi_lookup_irq being completely different it applies cleanly to 2.6.20-rc6
as well.
When I first looked at this problem I thought no big deal it will one
or two simple patches and that is it.
When I looked more closely I
The other big change is that I added a field to irq_desc to point
at the msi_desc. This removes the conflicts with the existing pointer
fields and makes the irq - msi_desc mapping useable outside of msi.c
I'm not even sure we would have needed that with Michael's mecanism in
fact. One other
Benjamin Herrenschmidt wrote:
The only architecture problem that isn't solvable in this context is
the problem of supporting the crazy hypervisor on the ppc RTAS, which
asks us to drive the hardware but does not give us access to the
hardware registers.
So you are saying that we should use
Jeff Garzik [EMAIL PROTECTED] writes:
Benjamin Herrenschmidt wrote:
The only architecture problem that isn't solvable in this context is
the problem of supporting the crazy hypervisor on the ppc RTAS, which
asks us to drive the hardware but does not give us access to the
hardware registers.
* Eric W. Biederman [EMAIL PROTECTED] wrote:
I'm not arguing against an operations based approach. I'm arguing for
simple obviously correct steps, and not throwing the baby out with the
bath water.
My patches should be a precursor to an operations based approach
because they are simple
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
The other big change is that I added a field to irq_desc to point
at the msi_desc. This removes the conflicts with the existing pointer
fields and makes the irq - msi_desc mapping useable outside of msi.c
I'm not even sure we would have
Jeff Garzik [EMAIL PROTECTED] writes:
I think the high-level ops approach makes more sense. It's more future proof,
in addition to covering all existing implementations.
To be precise in Michaels implementation one of the parameters passed is
a type parameter so that the architecture has to
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
.../... (enable/disable bits)
Which are either talking directly to the hardware, or are talking
to the hypervisor, which is using hardware isolation so it is safe to
talk directly to the hardware but isn't leting us? If we could use
things
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 16:26:44 -0700
Yes. In general the mainline linux kernel does not support certain
classes of stupidity. TCP offload engines, firmware drivers for
hardware we care about, a fixed ABI to binary only modules, etc.
It is the
From: Jeff Garzik [EMAIL PROTECTED]
Date: Sun, 28 Jan 2007 15:47:24 -0500
I think the high-level ops approach makes more sense. It's more future
proof, in addition to covering all existing implementations.
I totally agree with this.
-
To unsubscribe from this list: send the line unsubscribe
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 14:20:12 -0700
I see people pushing ridiculous interfaces like the RTAS hypervisor
interface at me, and saying we must support running firmware drivers
in the msi code.
This is not what's going on.
The hypervisor does the PCI
To be clear I see this as 2 distinct layers of code. enable/disable
that talks directly to the hardware, and the helpers of enable/disable
that allocate the irq. I base this on the fact that I only need the
alloc/free when I am exclusively working with real hardware.
We need the alloc/free
David Miller [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 16:26:44 -0700
Yes. In general the mainline linux kernel does not support certain
classes of stupidity. TCP offload engines, firmware drivers for
hardware we care about, a fixed ABI
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 22:18:59 -0700
Regardless of my opinion on the sanity of the hypervisor architects.
I have not seen anything that indicates it will be hard to support
the hypervisor doing everything or most of everything for us, so
I see no
David Miller [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 22:18:59 -0700
Regardless of my opinion on the sanity of the hypervisor architects.
I have not seen anything that indicates it will be hard to support
the hypervisor doing everything or
On Sun, 2007-01-28 at 21:25 -0800, David Miller wrote:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 22:18:59 -0700
Regardless of my opinion on the sanity of the hypervisor architects.
I have not seen anything that indicates it will be hard to support
the hypervisor
52 matches
Mail list logo
