From: Paul Durrant <Paul.Durrant@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Lars Kurth <lars.kurth@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
Julien Grall <julien.grall@linaro.org>,
"committers@xenproject.org" <committers@xenproject.org>,
xen-devel <xen-devel@lists.xenproject.org>,
Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: Commit moratorium to staging
Date: Thu, 2 Nov 2017 09:55:11 +0000 [thread overview]
Message-ID: <f2d56a961c894739a367bab0d479f814@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <20171102094210.cvth7v5m3irtwajh@dhcp-3-128.uk.xensource.com>
> -----Original Message-----
> From: Roger Pau Monne
> Sent: 02 November 2017 09:42
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@citrix.com>; Lars Kurth
> <lars.kurth@citrix.com>; Wei Liu <wei.liu2@citrix.com>; Julien Grall
> <julien.grall@linaro.org>; committers@xenproject.org; xen-devel <xen-
> devel@lists.xenproject.org>
> Subject: Re: [Xen-devel] Commit moratorium to staging
>
> On Thu, Nov 02, 2017 at 09:20:10AM +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Roger Pau Monne
> > > Sent: 02 November 2017 09:15
> > > To: Roger Pau Monne <roger.pau@citrix.com>
> > > Cc: Ian Jackson <Ian.Jackson@citrix.com>; Lars Kurth
> > > <lars.kurth@citrix.com>; Wei Liu <wei.liu2@citrix.com>; Julien Grall
> > > <julien.grall@linaro.org>; Paul Durrant <Paul.Durrant@citrix.com>;
> > > committers@xenproject.org; xen-devel <xen-
> devel@lists.xenproject.org>
> > > Subject: Re: [Xen-devel] Commit moratorium to staging
> > >
> > > On Wed, Nov 01, 2017 at 04:17:10PM +0000, Roger Pau Monné wrote:
> > > > On Wed, Nov 01, 2017 at 02:07:48PM +0000, Ian Jackson wrote:
> > > > > * Affected hosts differ from unaffected hosts according to cpuid.
> > > > > Roger has repro'd the bug on an unaffected host by masking out
> > > > > certain cpuid bits. There are 6 implicated bits and he is working
> > > > > to narrow that down.
> > > >
> > > > I'm currently trying to narrow this down and make sure the above is
> > > > accurate.
> > >
> > > So I was wrong with this, I guess I've run the tests on the wrong
> > > host. Even when masking the different cpuid bits in the guest the
> > > tests still succeeds.
> > >
> > > AFAICT the test fail or succeed reliably depending on the host
> > > hardware. I don't really have many ideas about what to do next, but I
> > > think it would be useful to create a manual osstest flight that runs
> > > the win16 job in all the different hosts in the colo. I would also
> > > capture the normal information that Xen collects after each test (xl
> > > info, /proc/cpuid, serial logs...).
> > >
> > > Is there anything else not captured by ts-logs-capture that would be
> > > interesting in order to help debug the issue?
> >
> > Does the shutdown reliably complete prior to migrate and then only fail
> intermittently after a localhost migrate?
>
> AFAICT yes, but it can also be added to the test in order to be sure.
>
> > It might be useful to know what cpuid info is seen by the guest before and
> after migrate.
>
> Is there anyway to get that from windows in an automatic way? If not I
> could test that with a Debian guest. In fact it might even be a good
> thing for Linux based guest to be added to the regular migration tests
> in order to make sure cpuid bits don't change across migrations.
>
I found this for windows:
https://www.cpuid.com/downloads/cpu-z/cpu-z_1.81-en.exe
It can generate a text or html report as well as being run interactively. But you may get more mileage from using a debian HVM guest. I guess it may also be useful is we can get a scan of available MSRs and content before and after migrate too.
> > Another datapoint... does the shutdown fail if you insert a delay of a couple
> of minutes between the migrate and the shutdown?
>
> Sometimes, after a variable number of calls to xl shutdown ... the
> guest usually ends up shutting down.
>
Hmm. I wonder whether the guest is actually healthy after the migrate. One could imagine a situation where the storage device model (IDE in our case I guess) gets stuck in some way but recovers after a timeout in the guest storage stack. Thus, if you happen to try shut down while it is still stuck Windows starts trying to shut down but can't. Try after the timeout though and it can.
In the past we did make attempts to support Windows without PV drivers in XenServer but xenrt would never reliably pass VM lifecycle tests using emulated devices. That was with qemu trad, but I wonder whether upstream qemu is actually any better particularly if using older device models such as IDE and RTL8139 (which are probably largely unmodified from trad).
Paul
> Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-11-02 9:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-02 8:19 [xen-unstable test] 115471: regressions - FAIL osstest service owner
2017-10-31 10:49 ` Commit moratorium to staging Julien Grall
2017-10-31 16:52 ` Roger Pau Monné
2017-11-01 10:48 ` Wei Liu
2017-11-01 11:00 ` Paul Durrant
2017-11-01 14:07 ` Ian Jackson
2017-11-01 14:59 ` Julien Grall
2017-11-01 16:54 ` Ian Jackson
2017-11-01 17:00 ` Julien Grall
2017-11-02 13:27 ` Commit moratorium to staging [and 1 more messages] Ian Jackson
2017-11-02 13:33 ` Julien Grall
2017-11-01 16:17 ` Commit moratorium to staging Roger Pau Monné
2017-11-02 9:15 ` Roger Pau Monné
2017-11-02 9:20 ` Paul Durrant
2017-11-02 9:42 ` Roger Pau Monné
2017-11-02 9:55 ` Paul Durrant [this message]
2017-11-03 14:14 ` Roger Pau Monné
2017-11-03 14:52 ` George Dunlap
2017-11-03 17:57 ` George Dunlap
2017-11-03 18:29 ` Roger Pau Monné
2017-11-03 18:35 ` Juergen Gross
2017-11-06 18:25 ` George Dunlap
2017-11-03 18:47 ` Ian Jackson
2017-11-02 12:05 ` Ian Jackson
2017-11-02 11:19 ` George Dunlap
-- strict thread matches above, loose matches on Subject: below --
2017-05-15 17:21 Julien Grall
2017-05-16 16:01 ` Ian Jackson
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=f2d56a961c894739a367bab0d479f814@AMSPEX02CL03.citrite.net \
--to=paul.durrant@citrix.com \
--cc=Ian.Jackson@citrix.com \
--cc=committers@xenproject.org \
--cc=julien.grall@linaro.org \
--cc=lars.kurth@citrix.com \
--cc=roger.pau@citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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 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).