lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <m18xdgkwgy.fsf@ebiederm.dsl.xmission.com>
Date:	Thu, 29 Mar 2007 07:31:09 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	michael@...erman.id.au
Cc:	linux-pci@...ey.karlin.mff.cuni.cz,
	Greg Kroah-Hartman <greg@...ah.com>,
	"David S. Miller" <davem@...emloft.net>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	daniel.e.wolstenholme@...el.com
Subject: Re: [PATCH 13/21] MSI: Do MSI masking in the arch code

Michael Ellerman <michael@...erman.id.au> writes:

>
> The main motivation was to have the arch in control of as much direct
> register writing as possible. Even though our HV does allow us to write
> to config space, it's not obviously safe for Linux to be flipping bits
> and also calling the HV to configure things. What's worse, I don't have
> hardware that supports the mask bits, so I can't test it.

I agree that there are limits here, on what we can feed into a hypervisor
and not confuse it.  Mostly my thinking is to assume someone has been
scribbling with the msi capability before we got there  and to place
everything in a know good state and not assume that device reset has
already done the work for us.  Since we aren't the pci  device reset
we can choose the defaults that make sense for us.

Worse case we can just put the capability in the state that pci device
reset would have put it in.

> I also thought this would save me from having custom MSI irq_chips for
> the powerpc backends. But I think I need them now anyway, so I guess
> that's not a concern.

Well we could still do the basic setup in arch_setup_msi_irq so I don't think
it has ever been an irq_chips style operations.

> So I guess we'll drop this one, although I might try and tidy up the
> implementation of "mask all MSIs" in msi_capability_init() as another
> patch.

I have no problem with that.  The msix version of this still needs
to be written as well.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ