On Tue, 2007-11-13 at 08:18 -0500, Gregory Haskins wrote:
> Since PCI was designed as a hardware solution it has all kinds of stuff
> specifically geared towards hardware constraints. Those constraints
> are different in a virtualized platform, so some things do not translate
> well to an optima
Avi Kivity wrote:
> Gregory Haskins wrote:
>>> PCI means that you can reuse all of the platform's infrastructure for
>>> irq allocation, discovery, device hotplug, and management.
>>>
>> Its tempting to use, yes. However, most of that infrastructure is
>> completely inappropriate for a PV imp
Gerd Hoffmann wrote:
Avi Kivity wrote:
You are
probably better off designing something that is PV specific instead of
shoehorning it in to fit a different model (at least for the things I
have in mind).
Well, if we design our pv devices to look like hardware, they will fit
quite wel
Avi Kivity wrote:
>> You are
>> probably better off designing something that is PV specific instead of
>> shoehorning it in to fit a different model (at least for the things I
>> have in mind).
>
> Well, if we design our pv devices to look like hardware, they will fit
> quite well. Both to the
Gregory Haskins wrote:
>
>> PCI means that you can reuse all of the platform's infrastructure for
>> irq allocation, discovery, device hotplug, and management.
>>
>
> Its tempting to use, yes. However, most of that infrastructure is
> completely inappropriate for a PV implementation, IMHO.
Avi Kivity wrote:
>
> I dislike strings. They make it look as if you have a nice extensible
> interface, where in reality you have a poorly documented interface which
> leads to poor interoperability.
Its not really a full fledged interface, but rather just a simple id
mechanism. A decentralize
Rusty Russell wrote:
On Wednesday 07 November 2007 16:40:13 Avi Kivity wrote:
Gregory Haskins wrote:
but FWIW: This is a major motivation for the reason that the
IOQ stuff I posted a while back used strings for device identification
instead of a fixed length, centrally managed namespac
Rusty Russell wrote:
On Wednesday 07 November 2007 16:40:13 Avi Kivity wrote:
Gregory Haskins wrote:
but FWIW: This is a major motivation for the reason that the
IOQ stuff I posted a while back used strings for device identification
instead of a fixed length, centrally managed namespac
On Wednesday 07 November 2007 16:40:13 Avi Kivity wrote:
> Gregory Haskins wrote:
> > but FWIW: This is a major motivation for the reason that the
> > IOQ stuff I posted a while back used strings for device identification
> > instead of a fixed length, centrally managed namespace like PCI
> > vend
Gregory Haskins wrote:
> Anthony Liguori wrote:
>
>
>> Right now, we would have to have every PCI vendor/device ID pair in the
>> virtio PCI driver ID table for every virtio device.
>>
>
> I realize you guys are probably far down this road in the design
> process,
That doesn't mean we can'
Anthony Liguori wrote:
>
> Right now, we would have to have every PCI vendor/device ID pair in the
> virtio PCI driver ID table for every virtio device.
I realize you guys are probably far down this road in the design
process, but FWIW: This is a major motivation for the reason that the
IOQ stuf
Anthony Liguori wrote:
Hi Rusty,
I've written a PCI virtio transport and noticed something strange.
All current in-tree virtio devices register ID tables that match a
specific device ID, but any vendor ID.
This is incompatible with using PCI vendor/device IDs for virtio
vendor/device IDs s
Hi Rusty,
I've written a PCI virtio transport and noticed something strange. All
current in-tree virtio devices register ID tables that match a specific
device ID, but any vendor ID.
This is incompatible with using PCI vendor/device IDs for virtio
vendor/device IDs since vendors control wha
13 matches
Mail list logo
