Arnd Bergmann wrote:
That being said, on platforms which are PCI-centric, such as x86, this
of course makes it a lot easier to produce virtual devices which work
across hypervisors, since the device model, of *any* operating system is
set up to handle them.
Yes, as I said there are two
On Wednesday 04 April 2007, H. Peter Anvin wrote:
> Configuration space access is platform-dependent. It's only defined to
> work in a specific way on x86 platforms.
>
> "Interrupt swizzling" is really totally independent of PCI. ALL PCI
> really provides is up to four interrupts per device
On Wednesday 04 April 2007, H. Peter Anvin wrote:
Configuration space access is platform-dependent. It's only defined to
work in a specific way on x86 platforms.
Interrupt swizzling is really totally independent of PCI. ALL PCI
really provides is up to four interrupts per device (not
Arnd Bergmann wrote:
That being said, on platforms which are PCI-centric, such as x86, this
of course makes it a lot easier to produce virtual devices which work
across hypervisors, since the device model, of *any* operating system is
set up to handle them.
Yes, as I said there are two
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, except
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, except on architectures
Arnd Bergmann wrote:
One interesting aspect of the PS3 hypervisor is that some of the
low-speed interfaces are implemented as a virtual UART, meaning
something that only has read and write operations and uses an
interrupt for flow control. The implementation in
drivers/ps3/vuart.c is probably
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
Jeremy Fitzhardinge wrote:
So, what you're saying is:
1. assuming there's going to be a vast number of miscellaneous devices
2. it would be best if there were one per device rather than one per
hypervisor per device
3. so we'd have one linux device driver
But this implies that
H. Peter Anvin wrote:
> However, there are other things; console is some, or my original
> example, which was random number generation. For those, the benefit
> of unification is proportionally greater, simply because the win of
> anything hypervisor-specific is much smaller.
So, what you're
On Tuesday 03 April 2007, Jeremy Fitzhardinge wrote:
> > Doing a SCSI driver has been tried before, with ibmvscsi. Not good.
> >
>
> OK, interesting. People had proposed using SCSI as the interface, but I
> wasn't aware of any results from doing that. How is it not good?
>
SCSI is really
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 all
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
On Tuesday 03 April 2007, Jeremy Fitzhardinge wrote:
> 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
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
On Tuesday 03 April 2007, Cornelia Huck 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 on *all*
On Tue, 3 Apr 2007 16:03:14 +0200,
Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> > > struct virt_dev {
> > > struct device dev;
> > > struct virt_driver *driver;
> > > struct virt_bus *bus;
> > > struct pci_device_id id;
> > > int irq;
> > > };
> >
> > And that's where I have problems :)
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
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
On Tue, 3 Apr 2007 14:15:37 +0200,
Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> Right, but an interesting point is the question what to do when running
> another operating system as a guest under Linux, e.g. with kvm.
>
> Ideally, you'd want to use the same interface to announce the presence
> of
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
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
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
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
>
> 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
On Tue, 3 Apr 2007 10:30:36 +0200,
Andi Kleen <[EMAIL PROTECTED]> wrote:
> 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
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?
> >
> >
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 emulated one with the appropiate device
> then distribution driver
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 emulated one with the appropiate device
then distribution driver auto
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 Tue, 3 Apr 2007 10:30:36 +0200,
Andi Kleen [EMAIL PROTECTED] wrote:
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
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 Tue, 3 Apr 2007 14:15:37 +0200,
Arnd Bergmann [EMAIL PROTECTED] wrote:
Right, but an interesting point is the question what to do when running
another operating system as a guest under Linux, e.g. with kvm.
Ideally, you'd want to use the same interface to announce the presence
of the
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
On Tue, 3 Apr 2007 16:03:14 +0200,
Arnd Bergmann [EMAIL PROTECTED] wrote:
struct virt_dev {
struct device dev;
struct virt_driver *driver;
struct virt_bus *bus;
struct pci_device_id id;
int irq;
};
And that's where I have problems :) The notion of irq is far
On Tuesday 03 April 2007, Cornelia Huck 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 on *all*
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
On Tuesday 03 April 2007, Jeremy Fitzhardinge wrote:
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.
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 all
On Tuesday 03 April 2007, Jeremy Fitzhardinge wrote:
Doing a SCSI driver has been tried before, with ibmvscsi. Not good.
OK, interesting. People had proposed using SCSI as the interface, but I
wasn't aware of any results from doing that. How is it not good?
SCSI is really
H. Peter Anvin wrote:
However, there are other things; console is some, or my original
example, which was random number generation. For those, the benefit
of unification is proportionally greater, simply because the win of
anything hypervisor-specific is much smaller.
So, what you're saying
Jeremy Fitzhardinge wrote:
So, what you're saying is:
1. assuming there's going to be a vast number of miscellaneous devices
2. it would be best if there were one per device rather than one per
hypervisor per device
3. so we'd have one linux device driver
But this implies that
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:
One interesting aspect of the PS3 hypervisor is that some of the
low-speed interfaces are implemented as a virtual UART, meaning
something that only has read and write operations and uses an
interrupt for flow control. The implementation in
drivers/ps3/vuart.c is probably
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, except on architectures that
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, except
Jeff Garzik wrote:
Sure, but let's look beyond device detection. For instance, it does not
necessarily follow that emulating PCI DMA is the best way to go for
communication with a virtual device, once detected.
This is true, of course. However, there are going to be a set of
virtual
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.
Sure, but let's look beyond device
Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
The implementation wouldn't need to use PCI at all. There wouldn't
even need to be PCI like registers internally. Just a pci device
with an ID somewhere in sysfs. PCI with unique IDs
is just a convenient and well established key into the driver
Anthony Liguori wrote:
> The actual PCI bus could paravirtualized. It's just a question of
> whether one reinvents a device discovery mechanism (like XenBus) or
> whether one piggy backs on existing mechanisms.
>
> Furthermore, in the future, I strongly suspect that HVM will become
> much more
Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
The implementation wouldn't need to use PCI at all. There wouldn't
even need to be PCI like registers internally. Just a pci device
with an ID somewhere in sysfs. PCI with unique IDs
is just a convenient and well established key into the driver
> > > Obviously, anyone who adheres to the published interface can
> > > use one of these VID:DIDs -- as far as I'm concerned, even
> > > hardware vendors; we'll use the SID to distinguish between
> > > implementations.
> > I think for this to work, some attempt at a conformance testing
> >
Andi Kleen wrote:
> The implementation wouldn't need to use PCI at all. There wouldn't
> even need to be PCI like registers internally. Just a pci device
> with an ID somewhere in sysfs. PCI with unique IDs
> is just a convenient and well established key into the driver module
> collection. Once
On Monday 02 April 2007 23:33:01 Jeff Garzik wrote:
> 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 emulated one with the appropiate device
> 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 emulated one with the appropiate device
then distribution driver auto probing would just work transparently for them.
-Andi
-
H. Peter Anvin wrote:
> On the subject of virtualization; there are a number of devices which
> keep being invented and reinvented by just about every virtualization
> vendor for no really good reason.
>
> I personally recently pointed out that a proper virtualization
> solution should handle
Roland Dreier wrote:
> Obviously, anyone who adheres to the published interface can use one
> of these VID:DIDs -- as far as I'm concerned, even hardware vendors;
> we'll use the SID to distinguish between implementations.
I think for this to work, some attempt at a conformance testing
> I would therefore like to propose that the Linux Foundation register a
> PCI ID for use by LANANA ($3000/year), and we set up a LANANA registry
> for these device IDs, together with a description of the device
> interface each of them expect. Similarly, a Subsystem ID registry can
> be
I would therefore like to propose that the Linux Foundation register a
PCI ID for use by LANANA ($3000/year), and we set up a LANANA registry
for these device IDs, together with a description of the device
interface each of them expect. Similarly, a Subsystem ID registry can
be used
Roland Dreier wrote:
Obviously, anyone who adheres to the published interface can use one
of these VID:DIDs -- as far as I'm concerned, even hardware vendors;
we'll use the SID to distinguish between implementations.
I think for this to work, some attempt at a conformance testing
program
H. Peter Anvin wrote:
On the subject of virtualization; there are a number of devices which
keep being invented and reinvented by just about every virtualization
vendor for no really good reason.
I personally recently pointed out that a proper virtualization
solution should handle entropy
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 emulated one with the appropiate device
then distribution driver auto probing would just work transparently for them.
-Andi
-
To
On Monday 02 April 2007 23:33:01 Jeff Garzik wrote:
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 emulated one with the appropiate device
then
Andi Kleen wrote:
The implementation wouldn't need to use PCI at all. There wouldn't
even need to be PCI like registers internally. Just a pci device
with an ID somewhere in sysfs. PCI with unique IDs
is just a convenient and well established key into the driver module
collection. Once you
Obviously, anyone who adheres to the published interface can
use one of these VID:DIDs -- as far as I'm concerned, even
hardware vendors; we'll use the SID to distinguish between
implementations.
I think for this to work, some attempt at a conformance testing
program is
Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
The implementation wouldn't need to use PCI at all. There wouldn't
even need to be PCI like registers internally. Just a pci device
with an ID somewhere in sysfs. PCI with unique IDs
is just a convenient and well established key into the driver
Anthony Liguori wrote:
The actual PCI bus could paravirtualized. It's just a question of
whether one reinvents a device discovery mechanism (like XenBus) or
whether one piggy backs on existing mechanisms.
Furthermore, in the future, I strongly suspect that HVM will become
much more
Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
The implementation wouldn't need to use PCI at all. There wouldn't
even need to be PCI like registers internally. Just a pci device
with an ID somewhere in sysfs. PCI with unique IDs
is just a convenient and well established key into the driver
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.
Sure, but let's look beyond device
Jeff Garzik wrote:
Sure, but let's look beyond device detection. For instance, it does not
necessarily follow that emulating PCI DMA is the best way to go for
communication with a virtual device, once detected.
This is true, of course. However, there are going to be a set of
virtual
76 matches
Mail list logo
