[Libvir] Here the patch for virtual CPU functions.
Daniel P. Berrange
berrange at redhat.com
Fri Aug 4 17:55:17 UTC 2006
On Fri, Aug 04, 2006 at 05:45:41AM -0400, Daniel Veillard wrote:
> On Thu, Aug 03, 2006 at 03:32:46PM +0200, Philippe Berthault wrote:
> > The patch (vcpus.diff) is joined with this mail.
> > To apply the patch, untar the libvirt-0.1.3.tar.gz archive (if not
> > already done).
> > Then in libvirt-0.1.3 directory, do
> > ./configure --prefix=/usr
> > if not already done, and after this:
> > patch -p1 < vcpus.diff
> > make
> > make install
> > From the initial patch of Michel Ponceau (not delivered), I've just
> > modify the virDomainGetVcpus function and added some useful macro for
> > bit manipulation in cpu bit maps.
> Excellent, thanks, I got it and reviewed it.
> I had a few things to change:
> - discard // based comments to stick just to /*
> - apply the header patch to libvirt.h.in not to the generated header
> - shorten some comments to fit in 80 characters wide
> - renamed the macros adding the VIR_ prefix to avoid potential name
> collision with other headers
> - Added TODOs in the front-end functions, as they should go through
> the driver API not calling Xen specific function directly
> If I remember correctly some points need to be sorted out there,
> any function with side effect should probably go though xend only
> when talking to a Xen virtualization
> - some cosmetic formatting changes
I've just reviewed the code you committed & it looks pretty sane to me. I'd
definitely want to hook up the driver API asap - it should be pretty easy
todo since the logic is already split out into appropriate backend files.
I'd really like to test it before we releease 0.1.4 but can't just yet - see
my point below..
> After those I think it was in a shape to be commited, so it's in but there
> is a few thing left to be done, see below:
> > TODO: These vcpus functions permits to dynamically change the vcpu/cpu
> > relation after the domain has been started but nothing has been done
> > regarding static cpus attribution in the XML configuration file of a domain.
> Yes there is a few things left:
> - as you said the impact on XML format (I'm not sure how much should be
> extracted though)
Whether we need the vcpu mapping in the XML really depends on whether its
useful to persist this stuff, or whether its something you can just define
at runtime as required. VCPU mappings really get into the realm of runtime
policy which I'm not convinced really wants/needs to be part of the basic
XML document data.
For example, when talking in terms of policy I don't think you'd directly
store info in terms of 'map vcpu-1 to host cpu 3'. Instead you'd probably
want to express it as 'give domain X a dedicated fixed CPU', or 'let domain
X share/float 3 cpus' with other domains. The policy/management app would then
decide which particular VCPU<->Host CPU mappings to implement when starting
up the domain. Such a decision would have to take into account existing VCPU
pinning from other domains already running.
So really IMHO we don't need to rush into adding VCPU mapping to the XML.
Better to wait and see if there are apps being created which explicitly
need this info persisted in the XML.
> - there is the driver cleanup, the VCPU entry points should be added
> to the interface, the front-end function should call the drivers
> and some tweaking might be needed in the Xen case to select when
> or when not to use direct hypervisor calls if available.
> - the doc and formal XML API need to be generated (make rebuild in doc)
> - in turn once the XML API is there, see how this affects Python binding
> generation, we will probably need to write specific glue to interface
> Python and make nicer functions there (using list instead of bitmaps
> - add tests
- expose the new APIs via virsh. Michael originally suggsted pretty much
following the style of 'xm vcpu-pin' and 'vcpu-list'. Seems like a fairly
reasonable pattern to follow.
> - then release 0.1.4
> Ahum, it's just a few things :-)
> I will probably take on the driver fixup first myself.
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
More information about the libvir-list