Ian Kirk wrote:
Avi Kivity wrote:
For mass storage, we should follow the SCSI model with a single device
serving multiple disks, similar to what you suggest. Not sure if the
device should have a single queue or one queue per disk.
Don't you just end up re-implementing SCSI then,
Anthony Liguori wrote:
BTW, I've never been that convinced that hotplugging devices is as
useful as people make it out to be. I also think that's particularly
true when it comes to hot adding/removing very large numbers of disks.
On the contrary, the more disks you have, the more
* Anthony Liguori ([EMAIL PROTECTED]) wrote:
Logically speaking, virtio is a bus. virtio supports all of the features
of a bus (discover, hot add, hot remove).
Right now, we map virtio devices directly onto the PCI bus.
The problem we're trying to address is limitations of the PCI bus. We
It sounds reasonable to expect so. ACPI has objects for devices, not
functions (IIRC).
So what I dislike about multifunction devices is the fact that a single
slot shares an IRQ, and that special code is required in the QEMU
drivers (virtio guest capability might not always be present).
This patch changes virtio devices to be multi-function devices whenever
possible. This increases the number of virtio devices we can support now by
a factor of 8.
With this patch, I've been able to launch a guest with either 220 disks or 220
network adapters.
I haven't tested the Windows virtio
Anthony Liguori wrote:
This patch changes virtio devices to be multi-function devices whenever
possible. This increases the number of virtio devices we can support now by
a factor of 8.
With this patch, I've been able to launch a guest with either 220 disks or 220
network adapters.
Avi Kivity wrote:
Anthony Liguori wrote:
This patch changes virtio devices to be multi-function devices whenever
possible. This increases the number of virtio devices we can support now by
a factor of 8.
With this patch, I've been able to launch a guest with either 220 disks or
220
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This patch changes virtio devices to be multi-function devices whenever
possible. This increases the number of virtio devices we can
support now by
a factor of 8.
With this patch, I've been able to launch a guest with
On Tue, Apr 22, 2008 at 4:15 PM, Anthony Liguori [EMAIL PROTECTED] wrote:
This patch changes virtio devices to be multi-function devices whenever
possible. This increases the number of virtio devices we can support now by
a factor of 8.
[...]
diff --git a/qemu/hw/virtio.c
* Anthony Liguori [EMAIL PROTECTED] [2008-04-22 09:16]:
This patch changes virtio devices to be multi-function devices whenever
possible. This increases the number of virtio devices we can support now by
a factor of 8.
With this patch, I've been able to launch a guest with either 220 disks
Ryan Harper wrote:
* Anthony Liguori [EMAIL PROTECTED] [2008-04-22 09:16]:
This patch changes virtio devices to be multi-function devices whenever
possible. This increases the number of virtio devices we can support now by
a factor of 8.
With this patch, I've been able to launch a guest
On Tue, Apr 22, 2008 at 05:32:45PM +0300, Avi Kivity wrote:
Anthony Liguori wrote:
This patch changes virtio devices to be multi-function devices whenever
possible. This increases the number of virtio devices we can support now by
a factor of 8.
With this patch, I've been able to
Marcelo Tosatti wrote:
Maybe require explicit device/function assignment on the command line?
It will be managed anyway.
ACPI does support hotplugging of individual functions inside slots,
not sure how well does Linux (and other OSes) support that.. should be
transparent though.
Anthony Liguori wrote:
I think we need to decide what we want to target in terms of upper
limits.
With a bridge or two, we can probably easily do 128.
If we really want to push things, I think we should do a PCI based
virtio controller. I doubt a large number of PCI devices is ever
Avi Kivity wrote:
Anthony Liguori wrote:
I think we need to decide what we want to target in terms of upper
limits.
With a bridge or two, we can probably easily do 128.
If we really want to push things, I think we should do a PCI based
virtio controller. I doubt a large number of PCI
On Tue, Apr 22, 2008 at 11:31:11AM -0500, Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
I think we need to decide what we want to target in terms of upper
limits.
With a bridge or two, we can probably easily do 128.
If we really want to push things, I think we should
For mass storage, we should follow the SCSI model with a single device
serving multiple disks, similar to what you suggest. Not sure if the
device should have a single queue or one queue per disk.
My latest thought it to do a virtio-based virtio controller.
Why do you
Avi Kivity wrote:
For mass storage, we should follow the SCSI model with a single device
serving multiple disks, similar to what you suggest. Not sure if the
device should have a single queue or one queue per disk.
Don't you just end up re-implementing SCSI then, at which point you might
as
Marcelo Tosatti wrote:
On Tue, Apr 22, 2008 at 05:32:45PM +0300, Avi Kivity wrote:
Anthony Liguori wrote:
This patch changes virtio devices to be multi-function devices whenever
possible. This increases the number of virtio devices we can support now by
a factor of 8.
With this
On Tue, Apr 22, 2008 at 02:26:45PM -0300, Marcelo Tosatti wrote:
On Tue, Apr 22, 2008 at 11:31:11AM -0500, Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
I think we need to decide what we want to target in terms of upper
limits.
With a bridge or two, we can
This patch changes virtio devices to be multi-function devices whenever
possible. This increases the number of virtio devices we can support now by
a factor of 8.
With this patch, I've been able to launch a guest with either 220 disks or 220
network adapters.
Since v1, I've changed the way
21 matches
Mail list logo
