On Nov 21, 2019, at 17:11, Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> wrote: > > On Thu, Nov 21, 2019 at 11:39:14AM -0800, Roman Shaposhnik wrote: >>> On Thu, Nov 21, 2019 at 9:38 AM Andrew Cooper <andrew.coop...@citrix.com> >>> wrote: >>> On 21/11/2019 17:31, Roman Shaposhnik wrote: >>>>>> On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß <jgr...@suse.com> 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). >> I'll make sure to test it on Fri, but here's where I'm lost -- my >> understanding that >> activation of this patch requires a special build flag to be passed.
Draft doc for the Xen 4.13 improvement: https://wiki.xen.org/wiki/Xen_EFI#Compatibility_of_UEFI_Host_Firmware.2C_Xen_and_UEFI_Runtime_Services Corrections and compatibility test reports would be welcome. Rich >> Which means, >> we're still very much in a regresses state when it comes to building >> out-of-the-box, >> no? > > No, there are two thing: > 1. A bug triggered by efi=no-rs flag - fixed in the above commit > 2. A second commit making efi=no-rs unnecessary on some machines - this > is what require build flag (CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y).
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
