Re: [Xen-devel] Status of 4.13

[Roman Shaposhnik <roman@xxxxxxxxxx>]

On Thu, Nov 21, 2019 at 9:38 AM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>
> On 21/11/2019 17:31, Roman Shaposhnik wrote:
> > On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß <jgross@xxxxxxxx> wrote:
> >> Where do we stand with Xen 4.13 regarding blockers and related patches?
> >>
> >> 1. OSStest failure regarding nested test:
> >>     I'm not quite sure whether the currently debated patch of Andrew is
> >>     fixing the problem. If not, do we know what is missing or how to
> >>     address the issue? If yes, could we please come to an agreement?
> >>     As an alternative: any thoughts about ignoring this test failure for
> >>     4.13-RC3 (IOW: doing a force push)?
> >>
> >> 2. Ryzen/Rome failures with Windows guests:
> >>     What is the currently planned way to address the problem? Who is
> >>     working on that?
> >>
> >> 3. Pending patches for 4.13:
> >>     Could I please have feedback which patches tagged as "for-4.13" are
> >>     fixing real regressions or issues? I don't want to take any patches
> >>     not fixing real problems after RC3, and I hope to be able to get a
> >>     push rather sooner than later to be able to let Ian cut RC3.
> >>
> >> 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
> >>     pending XSAs)?
> > Any chance the efi=no-rs regression can be added to the list? I understand
> > that I'm still on the hook to provide more details (I promise to do it on 
> > Fri
> > when I get to my lab to actually have a serial console on all these boxes).
> > At the same time this is a pretty serious regression for an entire class of
> > devices where Xen was perfectly happy even during RC1.
>
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=534f9e29ce28580892b3856036b5e5cd805667cc
> has been committed.  It is in staging, but not in master yet (because
> master is blocked by my regression in 1).

Reporting back after spending some time in the lab today:

1. Good news, the above patch takes care of the regression. I can now
add efi=no-rs
back and Xen boots (and also boots Dom0) on all the boxes involved.

2. Neutral news: Dell product line still requires efi=no-rs and
coredumps without it
(no regression -- that's I started using efi=no-rs to begin with).

3. Bad news: Marek's suggestion didn't work on Dell product line (and yes
I double checked that I built it correctly).

So... when it comes to RC2 regression -- we're all good.

But since we're here anyway -- I'm wondering if anyone would be
interested in helping me figure out why Xen on those Dell boxes coredumps
without efi=no-rs ?

Marek, any chance I can interest you in helping me a bit here? ;-)

Thanks,
Roman.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel