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 happ
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 dev
> 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 abl
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 u
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 pci_find_ca
> 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 devic
> 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 op
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 any
>
> 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
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 hyp
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 eve
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 n
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 f
> 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/fr
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 P
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 "unsubscr
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 use
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 t
.../... (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 to work around errata in card implementation de
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 are
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
>>> hardwa
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 your
> 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 oth
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 disco
27 matches
Mail list logo
