Carsten Otte wrote:
Avi Kivity wrote:
We intend to bind our virtio devices to PCI too, so that they look the
same in Linux userland across architectures.
Ouch.
That was my initial opinion too, but HPA has come up with a lean and
clean PCI binding for lguest. I think we should se
Avi Kivity wrote:
>> We intend to bind our virtio devices to PCI too, so that they look the
>> same in Linux userland across architectures.
>
> Ouch.
That was my initial opinion too, but HPA has come up with a lean and
clean PCI binding for lguest. I think we should seriously consider
using tha
Carsten Otte wrote:
>
>> [actually thinking a bit, this is specific to the virtio pci binding;
>> s390 will never see any of it]
> You remember that we've lost the big debate around virtio in Tucson?
I was in the embedded BOF.
> We intend to bind our virtio devices to PCI too, so that they look
Avi Kivity wrote:
> Unfortunately, we have to care for platform differences, subarch
> differences (vmx/svm), hypervisor differences (with virtio), and guest
> differences (Linux/Windows/pvLinux, 32/64). Much care is needed when
> designing the ABI here.
Yea, I agree.
> [actually thinking a bi
On Tuesday 27 November 2007, Avi Kivity wrote:
> > :-) Do you know if there is a hard limit on the number of devices on
> > a PCI bus? My concern was that it was limited by something stupid
> > like an 8-bit identifier.
>
> IIRC pci slots are 8-bit, but you can have multiple buses, so
> effec
Carsten Otte wrote:
> Avi Kivity wrote:
>
>> No, definitely not define a hypercall ABI. The feature bit should say
>> "this device understands a hypervisor-specific way of kicking. consult
>> your hypervisor manual and cpuid bits for further details. should you
>> not be satisfied with thi
Avi Kivity wrote:
> No, definitely not define a hypercall ABI. The feature bit should say
> "this device understands a hypervisor-specific way of kicking. consult
> your hypervisor manual and cpuid bits for further details. should you
> not be satisfied with this method, port io is still avai
Anthony Liguori wrote:
>> Another point is that virtio still has a lot of leading zeros in its
>> mileage counter. We need to keep things flexible and learn from
>> others as much as possible, especially when talking about the ABI.
>
> Yes, after thinking about it over holiday, I agree that we sh
Avi Kivity wrote:
> rx and tx are closely related. You rarely have one without the other.
>
> In fact, a turned implementation should have zero kicks or interrupts
> for bulk transfers. The rx interrupt on the host will process new tx
> descriptors and fill the guest's rx queue; the guest's trans
Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>> Well please propose the virtio API first and then I'll adjust the PCI
>>> ABI. I don't want to build things into the ABI that we never
>>> actually end up using in virtio :-)
>>>
>>>
>>>
>> Move ->kic
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Well please propose the virtio API first and then I'll adjust the PCI
>> ABI. I don't want to build things into the ABI that we never
>> actually end up using in virtio :-)
>>
>>
>
> Move ->kick() to virtio_driver.
Then on each kick, all queues h
Zachary Amsden wrote:
> On Wed, 2007-11-21 at 09:13 +0200, Avi Kivity wrote:
>
>
>> Where the device is implemented is an implementation detail that should
>> be hidden from the guest, isn't that one of the strengths of
>> virtualization? Two examples: a file-based block device implemented in
On Wed, 2007-11-21 at 09:13 +0200, Avi Kivity wrote:
> Where the device is implemented is an implementation detail that should
> be hidden from the guest, isn't that one of the strengths of
> virtualization? Two examples: a file-based block device implemented in
> qemu gives you fancy file for
Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>> Avi Kivity wrote:
>>>
>>>
Anthony Liguori wrote:
> This is a PCI device that implements a transport for virtio. It
> allows virtio
> devices to be used by QEMU ba
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>
>>> Anthony Liguori wrote:
>>>
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used
Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>> This is a PCI device that implements a transport for virtio. It
>>> allows virtio
>>> devices to be used by QEMU based VMMs like KVM or Xen.
>>>
>>> +
>>> +/* the notify function used when creating a virt queue
Avi Kivity wrote:
> Anthony Liguori wrote:
>> This is a PCI device that implements a transport for virtio. It
>> allows virtio
>> devices to be used by QEMU based VMMs like KVM or Xen.
>>
>> +
>> +/* the notify function used when creating a virt queue */
>> +static void vp_notify(struct virtqueue
Anthony Liguori wrote:
> This is a PCI device that implements a transport for virtio. It allows virtio
> devices to be used by QEMU based VMMs like KVM or Xen.
>
> +
> +/* the notify function used when creating a virt queue */
> +static void vp_notify(struct virtqueue *vq)
> +{
> + struct virt
On Thursday 08 November 2007, Anthony Liguori wrote:
>
> They already show up underneath of the PCI bus. The issue is that there
> are two separate 'struct device's for each virtio device. There's the
> PCI device (that's part of the pci_dev structure) and then there's the
> virtio_device one
Dor Laor wrote:
> Anthony Liguori wrote:
>> This is a PCI device that implements a transport for virtio. It
>> allows virtio
>> devices to be used by QEMU based VMMs like KVM or Xen.
>>
>>
>>
> While it's a little premature, we can start thinking of irq path
> improvements.
> The current
Anthony Liguori wrote:
> This is a PCI device that implements a transport for virtio. It allows virtio
> devices to be used by QEMU based VMMs like KVM or Xen.
>
>
>
While it's a little premature, we can start thinking of irq path
improvements.
The current patch acks a private isr and aft
Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>
>>> This is a PCI device that implements a transport for virtio. It allows
>>> virtio
>>> devices to be used by QEMU based VMMs like KVM or Xen.
>>>
>>>
>>>
>>>
>> Didn't see support for dma.
>>
Arnd Bergmann wrote:
> On Thursday 08 November 2007, Anthony Liguori wrote:
>
>> +/* A PCI device has it's own struct device and so does a virtio device so
>> + * we create a place for the virtio devices to show up in sysfs. I think it
>> + * would make more sense for virtio to not insist on ha
On Thursday 08 November 2007, Anthony Liguori wrote:
> +/* A PCI device has it's own struct device and so does a virtio device so
> + * we create a place for the virtio devices to show up in sysfs. I think it
> + * would make more sense for virtio to not insist on having it's own device.
> */
> +
On Thursday 08 November 2007, Anthony Liguori wrote:
> +/* A PCI device has it's own struct device and so does a virtio device so
> + * we create a place for the virtio devices to show up in sysfs. I think it
> + * would make more sense for virtio to not insist on having it's own device.
> */
> +
Anthony Liguori wrote:
> Avi Kivity wrote:
>> If a pci device is capable of dma (or issuing interrupts), it will be
>> useless with pv pci.
>
> Hrm, I think we may be talking about different things. Are you
> thinking that the driver I posted allows you to do PCI pass-through
> over virtio? Th
Avi Kivity wrote:
> If a pci device is capable of dma (or issuing interrupts), it will be
> useless with pv pci.
Hrm, I think we may be talking about different things. Are you thinking
that the driver I posted allows you to do PCI pass-through over virtio?
That's not what it is.
The driver I
Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>
>>> This is a PCI device that implements a transport for virtio. It
>>> allows virtio
>>> devices to be used by QEMU based VMMs like KVM or Xen.
>>>
>>>
>>
>> Didn't see support for dma.
>
> Not sure what you're expe
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>> This is a PCI device that implements a transport for virtio. It allows
>> virtio
>> devices to be used by QEMU based VMMs like KVM or Xen.
>>
>>
>>
>
> Didn't see support for dma.
Not sure what you're expecting there. Using dma_ops in v
Anthony Liguori wrote:
> This is a PCI device that implements a transport for virtio. It allows virtio
> devices to be used by QEMU based VMMs like KVM or Xen.
>
>
Didn't see support for dma. I think that with Amit's pvdma patches you
can support dma-capable devices as well without too much fu
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 9e33fc4..c81e0f3 100644
--- a/drivers/virtio/
31 matches
Mail list logo
