qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V4 01/10] NUMA: Support multiple CPU ranges on -


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH V4 01/10] NUMA: Support multiple CPU ranges on -numa option
Date: Mon, 8 Jul 2013 16:25:16 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Jul 08, 2013 at 01:02:41PM -0600, Eric Blake wrote:
> On 07/05/2013 12:41 PM, Eduardo Habkost wrote:
> > On Thu, Jul 04, 2013 at 05:53:08PM +0800, Wanlong Gao wrote:
> >> From: Bandan Das <address@hidden>
> >>
> >> This allows us to use the "cpus" property multiple times
> >> to specify multiple cpu (ranges) to the -numa option :
> >>
> >> -numa node,cpus=1,cpus=2,cpus=4
> >> or
> >> -numa node,cpus=1-3,cpus=5
> >>
> >> Note that after this patch, the defalut suffix of "-numa node,mem=N"
> >> will no longer be "M". So we must add the suffix "M" like "-numa 
> >> node,mem=NM"
> >> when assigning "N MB" of node memory size.
> > 
> > Such an incompatible change is not acceptable, as it would break
> > existing configurations. libvirt doesn't specify any suffix and expects
> > it to always mean "MB".
> 
> Newer libvirt can be taught to append 'M' when it detects it is talking
> to newer qemu.  While you have a point that it is annoying to force
> users to upgrade to a newer libvirt merely because they upgraded qemu,
> the libvirt point of view is that the following are supported:
> 
> old libvirt -> old qemu
> new libvirt -> old qemu
> new libvirt -> new qemu
> 
> but that this combination is always best effort and not required to work:
> 
> old libvirt -> new qemu

I assume the rules above apply only if "new libvirt" gets released
before "new qemu", right? Otherwise people won't be able to use latest
released libvirt with latest released qemu until "new libvirt" gets
released.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]