From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Cc: "george.dunlap@eu.citrix.com" <george.dunlap@eu.citrix.com>,
"Xu, YongweiX" <yongweix.xu@intel.com>,
"Liu, SongtaoX" <songtaox.liu@intel.com>,
"Tian, Yongxue" <yongxue.tian@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: test report for Xen 4.3 RC1
Date: Tue, 2 Jul 2013 09:36:12 -0400 [thread overview]
Message-ID: <20130702133612.GA4143@phenom.dumpdata.com> (raw)
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1001B2B2A8@SHSMSX102.ccr.corp.intel.com>
On Tue, Jul 02, 2013 at 08:09:48AM +0000, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Saturday, June 22, 2013 2:18 AM
> > To: Ren, Yongjie
> > Cc: george.dunlap@eu.citrix.com; Xu, YongweiX; Liu, SongtaoX; Tian,
> > Yongxue; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] test report for Xen 4.3 RC1
> >
> > > >
> > http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1851
> > > > > > > > > >
> > > > > > > > > > That looks like you are hitting the udev race.
> > > > > > > > > >
> > > > > > > > > > Could you verify that these patches:
> > > > > > > > > > https://lkml.org/lkml/2013/5/13/520
> > > > > > > > > >
> > > > > > > > > > fix the issue (They are destined for v3.11)
> > > > > > > > > >
> > > > > > > > > Not tried yet. I'll update it to you later.
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > > >
> > > > > > > We tested kernel 3.9.3 with the 2 patches you mentioned, and
> > found
> > > > this
> > > > > > > bug still exist. For example, we did CPU online-offline for Dom0 for
> > > > 100
> > > > > > times,
> > > > > > > and found 2 times (of 100 times) failed.
> > > > > >
> > > > > > Hm, does it fail b/c udev can't online the sysfs entry?
> > > > > >
> > > > > I think no.
> > > > > When it fails to online CPU #3 (trying online #1~#3), it doesn't show
> > any
> > > > info
> > > > > about CPU #3 via the output of "devadm monitor --env" CMD. It does
> > > > show
> > > > > info about #1 and #2 which are onlined succefully.
> > > >
> > > > And if you re-trigger the the 'xl vcpu-set' it eventually comes back up
> > right?
> > > >
> > > We don't use 'xl vcpu-set' command when doing the CPU hot-plug.
> > > We just call the xc_cpu_online/offline() in tools/libxc/xc_cpu_hotplug.c to
> > test.
> >
> > Oh. That is very different than what I thought. You are not offlining/onlining
> > vCPUS - you offlining/onlining pCPUS! So Xen has to cramp the dom0 vCPUs
> > in the
> > remaining vCPUS.
> >
> > There should be no vCPU re-sizing correct?
> >
> Yes, for this case we do online/offline for pCPUs not vCPUs.
> (vCPU number doesn't change.)
OK, so nothing to do with Linux but mostly with Xen hypervisor. Do you know
who added this functionality? Can they help?
>
> > > (see the attachment about my test code in that bugzilla.)
> > > And, yes, if a CPU failed to online, it can also be onlined again when we
> > re-trigger
> > > online function.
> > >
> > > > >
>
>
> > > > > > > > > > > 4. 'xl vcpu-set' can't decrease the vCPU number of a HVM
> > > > guest
> > > > > > > > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> > > > > > > > > >
> > > > > > > > > > That I believe was an QEMU bug:
> > > > > > > > > >
> > > > > >
> > http://lists.xen.org/archives/html/xen-devel/2013-05/msg01054.html
> > > > > > > > > >
> > > > > > > > > > which should be in QEMU traditional now (05-21 was when it
> > > > went
> > > > > > > > > > in the tree)
> > > > > > > > > >
> > > > > > > > > In this year or past year, this bug always exists (at least in our
> > > > > > testing).
> > > > > > > > > 'xl vcpu-set' can't decrease the vCPU number of a HVM guest
> > > > > > > >
> > > > > > > > Could you retry with Xen 4.3 please?
> > > > > > > >
> > > > > > > With Xen 4.3 & Linux:3.10.0-rc3, I can't decrease the vCPU
> > number of
> > > > a
> > > > > > guest.
> > > > > >
> > > > > sorry, when I said this message, I still use rhel6.4 kernel as the guest.
> > > > > After upgrading guest kernel to 3.10.0-rc3, the result became better.
> > > > > Basically vCPU increment/decrement can work fine. I'll close that
> > bug.
> > > >
> > > > Excellent!
> > > > > But there's still a minor issue as following.
> > > > > After booting guest with 'vcpus=4' and 'maxvcpus=32', change its
> > vCPU
> > > > number.
> > > > > # xl vcpu-set $domID 32
> > > > > then you can only get less than 32 (e.g. 19) CPUs in the guest; again,
> > you
> > > > set
> > > > > vCPU number to 32 (from 19), then it works to get 32vCPU for the
> > guest.
> > > > > but 'xl vcpu-set $domID 8' can work fine as we expected.
> > > > > vCPU decrement has the same result.
> > > > > Can you also have a try to reproduce my issue?
> > > >
> > > This issue doesn't exist when using the latest QEMU traditional tree.
> > > My pervious QEMU was old (March 2013), and I found some of your
> > patches
> > > were applied in May 2013. These fixes can fix the issue we reported.
> > > Close this bug.
> >
> > Yes!
> > >
> > > But, it introduced another issue: when doing 'xl vcpu-set' for HVM
> > several
> > > times (e.g. 5 times), the guest will panic. Log is attached.
> > > Before your patches in qemu traditional tree in May 2013, we never
> > meet
> > > guest kernel panic.
> > > dom0: 3.10.0-rc3
> > > Xen: 4.3.0-RCx
> > > QEMU: the latest traditional tree
> > > guest kernel: 3.10.0-RC3
> > > I'll file another bug to track this bug ?
> >
> > Please.
> > > Can you reproduce this ?
> >
> > Could you tell me how you are doing 'xl vcpu-set'? Is there a particular
> > test script you are using?
> >
> 1. xl vcpu-set $domID 2
> 2. xl vcpu-set $domID 20
> 3. repeat step #1 and #2 for several times. (guest kernel panic ...)
>
> I also filed a bug in bugzilla to track this.
> You can get more info in the following link.
> http://bugzilla.xenproject.org/bugzilla/show_bug.cgi?id=1860
OK, thank you.
I am a bit busy right now tracking down some other bugs that I promised
I would look after. But after that I should have some time.
>
> --
> Jay
>
>
> > >
> > > > Sure. Now how many PCPUS do you have? And what version of QEMU
> > > > traditional
> > > > were you using?
> > > >
> > > There're 32 pCPU in that system we used.
> > >
> > > Best Regards,
> > > Yongjie (Jay)
> >
>
next prev parent reply other threads:[~2013-07-02 13:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-16 4:10 test report for Xen 4.3 RC1 Ren, Yongjie
2013-06-17 14:23 ` Konrad Rzeszutek Wilk
2013-06-17 20:35 ` Konrad Rzeszutek Wilk
2013-06-17 20:36 ` Konrad Rzeszutek Wilk
2013-06-20 2:53 ` Ren, Yongjie
2013-06-21 18:17 ` Konrad Rzeszutek Wilk
2013-07-02 8:09 ` Ren, Yongjie
2013-07-02 13:36 ` Konrad Rzeszutek Wilk [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-06-05 10:14 Ren, Yongjie
2013-06-05 14:50 ` Konrad Rzeszutek Wilk
2013-06-04 15:59 Ren, Yongjie
2013-06-04 16:35 ` Konrad Rzeszutek Wilk
2013-05-27 3:49 Ren, Yongjie
2013-05-28 15:15 ` Konrad Rzeszutek Wilk
2013-05-28 15:21 ` Konrad Rzeszutek Wilk
2013-05-28 15:24 ` George Dunlap
2013-11-11 10:22 ` Ian Campbell
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=20130702133612.GA4143@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=george.dunlap@eu.citrix.com \
--cc=songtaox.liu@intel.com \
--cc=xen-devel@lists.xen.org \
--cc=yongjie.ren@intel.com \
--cc=yongweix.xu@intel.com \
--cc=yongxue.tian@intel.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).