On Tue, 2011-01-25 at 12:23 +0200, Avi Kivity wrote: > On 01/25/2011 07:37 AM, Alex Williamson wrote: > > On Mon, 2011-01-24 at 08:44 -0700, Alex Williamson wrote: > > > I'll look at how we might be > > > able to allocate slots on demand. Thanks, > > > > Here's a first cut just to see if this looks agreeable. This allows the > > slot array to grow on demand. This works with current userspace, as > > well as userspace trivially modified to double KVMState.slots and > > hotplugging enough pci-assign devices to exceed the previous limit (w/& > > w/o ept). Hopefully I got the rcu bits correct. Does this look like > > the right path? > > This can be trivially exhausted to pin all RAM.
What's a reasonable upper limit? A PCI device can have at most 6 MMIO BARs, each taking one slot. It might also support MSI-X in a way that splits a BAR, so an absolute max of 7 slots per PCI device. Assuming only 1 PCI bus for the moment and also assuming assigned devices are typically single function, 32 devices * 7 slots/device = 224 slots, so maybe a 256 limit? Maybe we even bump it up to a limit of 64 devices with a slot limit of 512. It would be easier in device assignment code to keep track of a number of devices limit than trying to guess whether slots will be available when we need them. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html