From: Alex Williamson <alex.williamson@redhat.com>
To: Chris Friesen <chris.friesen@genband.com>
Cc: kvm@vger.kernel.org
Subject: Re: problems starting kvm-qemu with 5+ virtual functions
Date: Wed, 11 Jul 2012 13:34:58 -0600 [thread overview]
Message-ID: <1342035298.2229.5.camel@bling.home> (raw)
In-Reply-To: <4FFDAF4A.1050402@genband.com>
On Wed, 2012-07-11 at 10:52 -0600, Chris Friesen wrote:
> Hi,
>
> We're running into a problem where we can't start up a single instance
> of kvm-qemu with 5 or more virtual functions (for the ethernet card)
> being passed to the guest. It's an Intel I350 NIC if it matters.
>
> I noticed a discussion in a thread titled "[RFC PATCH 0/2] Expose
> available KVM free memory slot count to help avoid aborts" that seemed
> to point to the hardcoded definition of KVM_MEMORY_SLOTS as being a
> possible problem, and proposed some patches to allow dynamic sizing of
> the number of memory slots. It looks like that patch never went through
> to mainline though.
>
> Is this likely the source of my problem?
Yes, that's the problem.
> Why didn't it ever get submitted to mainline.
There were issues with extending the number of available memory slots.
By itself, those patches just prevent an abort, but don't really let you
add more devices.
> What's the proper method of supporting 8 VFs per VM, with possibly
> several VMs?
The limiting factor to increasing memory slots was searching the array.
That's since been fixed by caching mmio page table entries. AIUI, Avi
is now willing to accept a patch to bump memory slots to a much higher
value. The number of available slots can be queried by qemu using
KVM_CAP_NR_MEMSLOTS, then something like the RFC you point at could be
used to allow device assignment to take advantage of that. Thanks,
Alex
next prev parent reply other threads:[~2012-07-11 19:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-11 16:52 problems starting kvm-qemu with 5+ virtual functions Chris Friesen
2012-07-11 19:34 ` Alex Williamson [this message]
2012-07-11 19:56 ` Chris Friesen
2012-07-11 20:06 ` Alex Williamson
2012-07-11 21:08 ` Chris Friesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1342035298.2229.5.camel@bling.home \
--to=alex.williamson@redhat.com \
--cc=chris.friesen@genband.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.