Mailing List Archive: Xen: Devel

Xen 4.2 TODO / Release Plan

1 2

View All

Index | Next | Previous | View Threaded

JBeulich at suse

Aug 7, 2012, 1:05 AM

Post #26 of 34 (59 views)
Permalink

Re: Xen 4.2 TODO / Release Plan [In reply to]

>>> On 07.08.12 at 09:50, Keir Fraser <keir.xen [at] gmail> wrote:
> On 07/08/2012 07:38, "Jan Beulich" <JBeulich [at] suse> wrote:
>
>> Otoh, restoring from saved state that only includes MCG_CAP (but
>> no MCi_CTL2-s) needs to be handled anyway (forcing MCi_CTL2
>> to be zero, which would be trivial as that's the startup state, i.e.
>> the only complication here is the variable size save record), so
>> pushing this to post-4.2 as well is a reasonable alternative.
>>
>> Keir, Ian?
>
> I think we should leave it and handle the variable-sized save record in 4.3.
> Using hvm_load_entry_zeroextend() to read in save records, with zero padding
> for older shorter records, should be straightforward enough.

Okay. So Ian, you could then take the corresponding item
off the list. Or do you do that only once patches make it
through the regression tester?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

Ian.Campbell at citrix

Aug 7, 2012, 1:10 AM

Post #27 of 34 (57 views)
Permalink

Re: Xen 4.2 TODO / Release Plan [In reply to]

On Tue, 2012-08-07 at 09:05 +0100, Jan Beulich wrote:
> >>> On 07.08.12 at 09:50, Keir Fraser <keir.xen [at] gmail> wrote:
> > On 07/08/2012 07:38, "Jan Beulich" <JBeulich [at] suse> wrote:
> >
> >> Otoh, restoring from saved state that only includes MCG_CAP (but
> >> no MCi_CTL2-s) needs to be handled anyway (forcing MCi_CTL2
> >> to be zero, which would be trivial as that's the startup state, i.e.
> >> the only complication here is the variable size save record), so
> >> pushing this to post-4.2 as well is a reasonable alternative.
> >>
> >> Keir, Ian?
> >
> > I think we should leave it and handle the variable-sized save record in 4.3.
> > Using hvm_load_entry_zeroextend() to read in save records, with zero padding
> > for older shorter records, should be straightforward enough.
>
> Okay. So Ian, you could then take the corresponding item
> off the list. Or do you do that only once patches make it
> through the regression tester?

I'll mark it as done for 4.2.

>
> Jan
>

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

jinsong.liu at intel

Aug 7, 2012, 11:13 AM

Post #28 of 34 (56 views)
Permalink

Re: Xen 4.2 TODO / Release Plan [In reply to]

Jan Beulich wrote:
>>>> On 07.08.12 at 09:50, Keir Fraser <keir.xen [at] gmail> wrote:
>> On 07/08/2012 07:38, "Jan Beulich" <JBeulich [at] suse> wrote:
>>
>>> Otoh, restoring from saved state that only includes MCG_CAP (but
>>> no MCi_CTL2-s) needs to be handled anyway (forcing MCi_CTL2
>>> to be zero, which would be trivial as that's the startup state, i.e.
>>> the only complication here is the variable size save record), so
>>> pushing this to post-4.2 as well is a reasonable alternative.
>>>
>>> Keir, Ian?
>>
>> I think we should leave it and handle the variable-sized save record
>> in 4.3. Using hvm_load_entry_zeroextend() to read in save records,
>> with zero padding for older shorter records, should be
>> straightforward enough.
>
> Okay. So Ian, you could then take the corresponding item
> off the list. Or do you do that only once patches make it
> through the regression tester?
>

So we will leave it and handle it after 4.2, right?
I will take 1 week vacation start from tomorrow, so Jan, if anythting misunderstanding please let me know asap.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

JBeulich at suse

Aug 7, 2012, 11:37 PM

Post #29 of 34 (57 views)
Permalink

Re: Xen 4.2 TODO / Release Plan [In reply to]

>>> On 07.08.12 at 20:13, "Liu, Jinsong" <jinsong.liu [at] intel> wrote:
> Jan Beulich wrote:
>>>>> On 07.08.12 at 09:50, Keir Fraser <keir.xen [at] gmail> wrote:
>>> On 07/08/2012 07:38, "Jan Beulich" <JBeulich [at] suse> wrote:
>>>
>>>> Otoh, restoring from saved state that only includes MCG_CAP (but
>>>> no MCi_CTL2-s) needs to be handled anyway (forcing MCi_CTL2
>>>> to be zero, which would be trivial as that's the startup state, i.e.
>>>> the only complication here is the variable size save record), so
>>>> pushing this to post-4.2 as well is a reasonable alternative.
>>>>
>>>> Keir, Ian?
>>>
>>> I think we should leave it and handle the variable-sized save record
>>> in 4.3. Using hvm_load_entry_zeroextend() to read in save records,
>>> with zero padding for older shorter records, should be
>>> straightforward enough.
>>
>> Okay. So Ian, you could then take the corresponding item
>> off the list. Or do you do that only once patches make it
>> through the regression tester?
>>
>
> So we will leave it and handle it after 4.2, right?

Yes. It would be nice if you could then resubmit the rest of
the series, addressing pending review comments.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

Ian.Campbell at citrix

Aug 21, 2012, 8:27 AM

Post #30 of 34 (54 views)
Permalink

Re: Xen 4.2 TODO / Release Plan [In reply to]

Users list to BCC.

On Tue, 2012-08-21 at 16:14 +0100, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: xen-devel-bounces [at] lists
> > [mailto:xen-devel-bounces [at] lists] On Behalf Of Ian Campbell
> > Sent: Monday, August 20, 2012 5:17 PM
> > To: xen-devel; xen-users
> > Subject: [Xen-devel] Xen 4.2 TODO / Release Plan
> >
> > * [BUG] long stop during the guest boot process with qcow image,
> > reported by Intel:
> > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
> >
> After reverting the "O_DIRECT for IDE" patch in qemu-xen tree, it works as fine as that before the bug.
> But it still have some stop time (about 8~10s) after loading the Grub for a RHEL6.x guest.
> I found even an old CS #23124 (about 1 year ago) also has the same phenomenon.

23124 here is e3d4c34b14a3112481b5e86ff2406cd1bb5e1548 which is some
sort of tools build fix. What is the long hash of the changeset you are
referring to?

> Currently, RHEL6.2 or RHEL6.3 guest can bootup in 30~40s (for either RAW or QCOW2 image).
> And, RHEL5.5 guest (which has no stop time issue) can bootup in 50~60s.
>
> I also commented in the bugzilla. You can also have a look for more details.
>
> Will you want still track or fix this old issue ? If not, I want to marked it as "fixed and verified".

If you think the issue is fixed then I will mark it done on the todo
list.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

yongjie.ren at intel

Aug 21, 2012, 8:49 AM

Post #31 of 34 (53 views)
Permalink

Re: Xen 4.2 TODO / Release Plan [In reply to]

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell [at] citrix]
> Sent: Tuesday, August 21, 2012 11:27 PM
> To: Ren, Yongjie
> Cc: xen-devel
> Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
>
> Users list to BCC.
>
> On Tue, 2012-08-21 at 16:14 +0100, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: xen-devel-bounces [at] lists
> > > [mailto:xen-devel-bounces [at] lists] On Behalf Of Ian Campbell
> > > Sent: Monday, August 20, 2012 5:17 PM
> > > To: xen-devel; xen-users
> > > Subject: [Xen-devel] Xen 4.2 TODO / Release Plan
> > >
> > > * [BUG] long stop during the guest boot process with qcow
> image,
> > > reported by Intel:
> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
> > >
> > After reverting the "O_DIRECT for IDE" patch in qemu-xen tree, it works
> as fine as that before the bug.
> > But it still have some stop time (about 8~10s) after loading the Grub for a
> RHEL6.x guest.
> > I found even an old CS #23124 (about 1 year ago) also has the same
> phenomenon.
>
> 23124 here is e3d4c34b14a3112481b5e86ff2406cd1bb5e1548 which is
> some
> sort of tools build fix. What is the long hash of the changeset you are
> referring to?
>
Yes, it's "changeset: 23124:e3d4c34b14a3".
That changeset is picked out randomly just to confirm the stop time (8~10s) should already exist for a long time.

> > Currently, RHEL6.2 or RHEL6.3 guest can bootup in 30~40s (for either
> RAW or QCOW2 image).
> > And, RHEL5.5 guest (which has no stop time issue) can bootup in 50~60s.
> >
> > I also commented in the bugzilla. You can also have a look for more
> details.
> >
> > Will you want still track or fix this old issue ? If not, I want to marked it
> as "fixed and verified".
>
> If you think the issue is fixed then I will mark it done on the todo
> list.
>
I think yes. The regression for long stop time (about 50s) in bootup for qcow2 image has already been fixed.
Now, 30s for a guest booting up is acceptable from my viewpoint.
If the 8~10 stop time really matters, we can setup another thread to discuss it.
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

JBeulich at suse

Aug 21, 2012, 9:08 AM

Post #32 of 34 (51 views)
Permalink

Re: Xen 4.2 TODO / Release Plan [In reply to]

>>> On 21.08.12 at 17:39, Ben Guthro <ben [at] guthro> wrote:
> On Mon, Aug 20, 2012 at 5:17 AM, Ian Campbell <Ian.Campbell [at] citrix> wrote:
>>
>> * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>>
>
> No significant progress made on this since the last update.
> More questions raised than answers found. I'm having trouble making
> sense of the current test results.
>
> More debugging is needed. Jan is working on a debug patch to give to me.

I haven't been able to get to this yesterday and today, and will
be working only half day tomorrow. After that I'll be traveling,
so it may well end up being only after the return from the summit
that I may be able to get you something.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

konrad at kernel

Aug 31, 2012, 10:42 AM

Post #33 of 34 (50 views)
Permalink

Re: Xen 4.2 TODO / Release Plan [In reply to]

On Fri, Aug 31, 2012 at 10:36:47AM -0700, George Dunlap wrote:
> On Tue, Aug 28, 2012 at 3:06 AM, Ian Campbell <Ian.Campbell [at] citrix> wrote:
> > * [BUG] qemu-traditional has 50% cpu utilization on an idle
> > Windows system if USB is enabled. Not 100% clear whether this is
> > Xen or qemu. George Dunlap is performing initial
> > investigations.
>
> So it's hard to get directly comparable results, but I think that
> early indications are that the biggest chunk of this is due to the
> extra syscall overhead for a 64-bit dom0. Data points are:
> 1. Ubuntu 12.04, 64-bit, pvops Ubuntu kernel, Xen 4.2-rc2, older AMD
> system: qemu uses 50% on an idle system

So what happens if you run with a 32-bit dom0? What is the kernel
version? There were some issues with extra traps being done due to the
cpuidle running (which it should not).

> 2. XenServer built with Xen-4.2; (32-bit 2.6.32 dom0), Nehalem system:
> <qemu uses 2% on an idle system
> 3. Debian wheezy with the squeeze 2.6.32 32-bit kernel, older AMD
> system: qemu uses 10% on an idle system

Can you try booting with 'nohz=off'. What does 'perf top' (you need to
run v3.4 or later) give you?

>
> Looking at the traces, it seems that on the AMD box there were just a
> whole lot more USB-related IO accesses than on the Nehalem system. #2
> had far fewer USB-related accesses than #1, but #3 had about twice as
> many as #1. So it seems likely to be a combination between something
> weird that the USB driver in the guest is doing under AMD, and the
> extra overhead of a 64-bit kernel.
>
> So I think this is probably OK to take off the blocker list (although
> it's probably something we want to look into further).
>
> -George
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel [at] lists
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

Ian.Campbell at citrix

Sep 3, 2012, 2:10 AM

Post #34 of 34 (45 views)
Permalink

Re: Xen 4.2 TODO / Release Plan [In reply to]

On Fri, 2012-08-31 at 18:26 +0100, George Dunlap wrote:
> On Tue, Aug 28, 2012 at 3:06 AM, Ian Campbell <Ian.Campbell [at] citrix> wrote:
> > hypervisor, nice to have:
> >
> > * [BUG(?)] Under certain conditions, the p2m_pod_sweep code will
> > stop halfway through searching, causing a guest to crash even if
> > there was zeroed memory available. This is NOT a regression
> > from 4.1, and is a very rare case, so probably shouldn't be a
> > blocker. (In fact, I'd be open to the idea that it should wait
> > until after the release to get more testing.)
> > (George Dunlap)
>
> I probably won't get a chance to work on this until I get back
> mid-september, so this shouldn't be a blocker.

No problem. Since we hope to do the final RC this week that effectively
means its pushed out to 4.3 so I'll mark it as such.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads