qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Zhuangyanying <ann.zhuangyanying@huawei.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
	Zhanghailiang <zhang.zhanghailiang@huawei.com>,
	"wangxin (U)" <wangxinxin.wang@huawei.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	Huangzhichao <huangzhichao@huawei.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"Zhangbo (Oscar)" <oscar.zhangbo@huawei.com>,
	ehabkost@redhat.com
Subject: Re: [Qemu-devel] [BUG] Migrate failes between boards with different PMC counts
Date: Tue, 25 Apr 2017 18:20:17 +0100	[thread overview]
Message-ID: <20170425172017.GB17122@work-vm> (raw)
In-Reply-To: <EC9759BC1E3E98429B5DE9A03DF86D8B59D10917@DGGEML503-MBX.china.huawei.com>

* Zhuangyanying (ann.zhuangyanying@huawei.com) wrote:
> 
> 
> > -----Original Message-----
> > From: Daniel P. Berrange [mailto:berrange@redhat.com]
> > Sent: Monday, April 24, 2017 6:34 PM
> > To: Dr. David Alan Gilbert
> > Cc: Zhuangyanying; Zhanghailiang; wangxin (U); qemu-devel@nongnu.org;
> > Gonglei (Arei); Huangzhichao; pbonzini@redhat.com
> > Subject: Re: [Qemu-devel] [BUG] Migrate failes between boards with different
> > PMC counts
> > 
> > On Mon, Apr 24, 2017 at 11:27:16AM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (berrange@redhat.com) wrote:
> > > > On Mon, Apr 24, 2017 at 10:23:21AM +0100, Dr. David Alan Gilbert wrote:
> > > > > * Zhuangyanying (ann.zhuangyanying@huawei.com) wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > Recently, I found migration failed when enable vPMU.
> > > > > >
> > > > > > migrate vPMU state was introduced in linux-3.10 + qemu-1.7.
> > > > > >
> > > > > > As long as enable vPMU, qemu will save / load the
> > > > > > vmstate_msr_architectural_pmu(msr_global_ctrl) register during the
> > migration.
> > > > > > But global_ctrl generated based on cpuid(0xA), the number of
> > > > > > general-purpose performance monitoring counters(PMC) can vary
> > > > > > according to Intel SDN. The number of PMC presented to vm, does
> > > > > > not support configuration currently, it depend on host cpuid, and enable
> > all pmc defaultly at KVM. It cause migration to fail between boards with
> > different PMC counts.
> > > > > >
> > > > > > The return value of cpuid (0xA) is different dur to cpu, according to Intel
> > SDN,18-10 Vol. 3B:
> > > > > >
> > > > > > Note: The number of general-purpose performance monitoring
> > > > > > counters (i.e. N in Figure 18-9) can vary across processor
> > > > > > generations within a processor family, across processor
> > > > > > families, or could be different depending on the configuration
> > > > > > chosen at boot time in the BIOS regarding Intel Hyper Threading
> > > > > > Technology, (e.g. N=2 for 45 nm Intel Atom processors; N =4 for
> > processors based on the Nehalem microarchitecture; for processors based on
> > the Sandy Bridge microarchitecture, N = 4 if Intel Hyper Threading Technology
> > is active and N=8 if not active).
> > > > > >
> > > > > > Also I found, N=8 if HT is not active based on the broadwell,,
> > > > > > such as CPU E7-8890 v4 @ 2.20GHz
> > > > > >
> > > > > > # ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 4 -m
> > > > > > 4096 -hda
> > > > > > /data/zyy/test_qemu.img.sles12sp1 -vnc :99 -cpu kvm64,pmu=true
> > > > > > -incoming tcp::8888 Completed 100 %
> > > > > > qemu-system-x86_64: error: failed to set MSR 0x38f to
> > > > > > 0x7000000ff
> > > > > > qemu-system-x86_64: /data/zyy/git/test/qemu/target/i386/kvm.c:1833:
> > kvm_put_msrs:
> > > > > > Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
> > > > > > Aborted
> > > > > >
> > > > > > So make number of pmc configurable to vm ? Any better idea ?
> > > > >
> > > > > Coincidentally we hit a similar problem a few days ago with -cpu
> > > > > host  - it took me quite a while to spot the difference between
> > > > > the machines was the source had hyperthreading disabled.
> > > > >
> > > > > An option to set the number of counters makes sense to me; but I
> > > > > wonder how many other options we need as well.  Also, I'm not sure
> > > > > there's any easy way for libvirt etc to figure out how many
> > > > > counters a host supports - it's not in /proc/cpuinfo.
> > > >
> > > > We actually try to avoid /proc/cpuinfo whereever possible. We do
> > > > direct CPUID asm instructions to identify features, and prefer to
> > > > use /sys/devices/system/cpu if that has suitable data
> > > >
> > > > Where do the PMC counts come from originally ? CPUID or something
> > else ?
> > >
> > > Yes, they're bits 8..15 of CPUID leaf 0xa
> > 
> > Ok, that's easy enough for libvirt to detect then. More a question of what libvirt
> > should then do this with the info....
> > 
> 
> Do you mean to do a validation at the begining of migration? in qemuMigrationBakeCookie() & qemuMigrationEatCookie(), if the PMC numbers are not equal, just quit migration?
> It maybe a good enough first edition.
> But for a further better edition, maybe it's better to support Heterogeneous migration I think, so we might need to make PMC number configrable, then we need to modify KVM/qemu as well.

Yes agreed; the only thing I wanted to check was that libvirt would have enough
information to be able to use any feature we added to QEMU.

Dave

> Regards,
> -Zhuang Yanying
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

      reply	other threads:[~2017-04-25 17:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24  6:26 [Qemu-devel] [BUG] Migrate failes between boards with different PMC counts Zhuangyanying
2017-04-24  9:23 ` Dr. David Alan Gilbert
2017-04-24  9:52   ` Daniel P. Berrange
2017-04-24 10:27     ` Dr. David Alan Gilbert
2017-04-24 10:34       ` Daniel P. Berrange
2017-04-24 12:57         ` Zhuangyanying
2017-04-25 17:20           ` Dr. David Alan Gilbert [this message]

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=20170425172017.GB17122@work-vm \
    --to=dgilbert@redhat.com \
    --cc=ann.zhuangyanying@huawei.com \
    --cc=arei.gonglei@huawei.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=huangzhichao@huawei.com \
    --cc=oscar.zhangbo@huawei.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wangxinxin.wang@huawei.com \
    --cc=zhang.zhanghailiang@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).