On Tuesday 03 April 2007 10:29:06 Christian Borntraeger wrote:
On Monday 02 April 2007 23:12, Andi Kleen wrote:
How would that work in the case where virtualized guests don't have a
visible PCI bus, and the virtual environment doesn't pretend to emulate
a PCI bus?
If they
On s390, it would be more than strangeness. There's no implementation
of PCI at all, someone would have to cook it up - and it wouldn't have
any use beyond those special devices. Since there isn't any bus type
that is available on *all* architectures, a generic virtual bus with
very simple
On Tuesday 03 April 2007, H. Peter Anvin wrote:
However, one probably wants to think about what the heck one actually
means with virtualization in the absence of a lot of this stuff. PCI
is probably the closest thing we have to a lowest common denominator for
device detection.
I think
On Tue, 3 Apr 2007 11:41:49 +0200,
Arnd Bergmann [EMAIL PROTECTED] wrote:
On Tuesday 03 April 2007, H. Peter Anvin wrote:
However, one probably wants to think about what the heck one actually
means with virtualization in the absence of a lot of this stuff. PCI
is probably the closest
On Tue, 3 Apr 2007 11:26:52 +0200,
Andi Kleen [EMAIL PROTECTED] wrote:
On s390, it would be more than strangeness. There's no implementation
of PCI at all, someone would have to cook it up - and it wouldn't have
any use beyond those special devices. Since there isn't any bus type
that
On Tuesday 03 April 2007, Cornelia Huck wrote:
I think that's true outside of s390, but a standardized virtual device
interface should be able to work there as well. Interestingly, the
s390 channel I/O also uses two 16 bit numbers to identify a device
(type and model), just like PCI or
On Tuesday 03 April 2007, Cornelia Huck wrote:
On Tue, 3 Apr 2007 14:15:37 +0200, Arnd Bergmann [EMAIL PROTECTED] wrote:
That's OK for a virtualized architecture where the base architecture
already supports PCI. But a traditional s390 OS would be as unhappy
with a PCI device as with a device
On Tue, Apr 03, 2007 at 11:26:52AM +0200, Andi Kleen wrote:
On s390, it would be more than strangeness. There's no implementation
of PCI at all, someone would have to cook it up - and it wouldn't have
any use beyond those special devices. Since there isn't any bus type
that is available
Arnd Bergmann wrote:
I think we need to separate two problems here:
1. Probing:
That's really what triggered the discussion, PCI probing is well-understood
and implemented on _most_ platforms, so there is some value in reusing it.
When you talk about 'very simple probing', I'm not sure what
Arnd Bergmann wrote:
We already have device drivers for physical devices that can be attached
to different buses. The EHCI USB is an example of a driver that can
be for instance PCI, OF or an on-chip device. Moreover, you can have an
abstracted device behind it that does not need to know
Jeremy Fitzhardinge wrote:
Yes, and that's the core of the Xen netfront. But is there really much
code which can be shared between different hypervisors? When you get
down to it, all the real code is hypervisor-specific stuff for setting
up ringbuffers and dealing with interrupts. Like
On Tuesday 03 April 2007, Jeremy Fitzhardinge wrote:
That said, something like USB is probably the best bet for this kind of
low-performance device. I think. Not that I really know anything about
USB.
USB has the disadvantage that it is more complex than PCI and requires
significantly more
Arnd Bergmann wrote:
On Wednesday 04 April 2007, H. Peter Anvin wrote:
Note that at least for PIO-based devices, there is nothing that says you
can't implement PCI over another transport, if you wish. It's really
just a very simple RPC protocol.
The PIO aspect of PCI is simple, yes,
Add noreplace-smp to disable SMP instruction replacement.
Signed-off-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
---
Documentation/kernel-parameters.txt |6 ++
arch/i386/kernel/alternative.c | 23 +++
2 files changed, 25 insertions(+), 4 deletions(-)
The other symbols used to delineate the alt-instructions sections have
the form __foo/__foo_end. Rename parainstructions to match.
Signed-off-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Rusty Russell [EMAIL PROTECTED]
---
arch/i386/kernel/alternative.c |6
Everyone wants VDSO to be enabled by default. COMPAT_VDSO still needs
a fix, but with luck that will turn up soon.
Signed-off-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
---
arch/i386/kernel/sysenter.c |4
1 file changed, 4 deletions(-)
16 matches
Mail list logo
