From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Lagerwall Subject: Re: [PATCH] xen/video: Set EFI framebuffer to WC by default Date: Thu, 11 Jun 2015 14:03:37 +0100 Message-ID: <55798729.20208@citrix.com> References: <1434024581-26432-1-git-send-email-ross.lagerwall@citrix.com> <55799CA20200007800083A81@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55799CA20200007800083A81@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Keir Fraser , Tim Deegan , Ian Jackson , Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 06/11/2015 01:35 PM, Jan Beulich wrote: >>>> On 11.06.15 at 14:09, wrote: >> Set the EFI framebuffer to write-combining by default. This makes >> booting somewhat faster, but more importantly avoids tripping the >> watchdog. In particular, before on my test machine, each frame redraw >> would take around 80ms, which can trip the 5s watchdog when constructing >> dom0, since it outputs something like 60 lines without processing >> pending softirqs. > > That would need fixing then. What are those 60 lines? I think it's the lines from "Testing NMI watchdog on all CPUs: ok" to "Scrubbing Free RAM". > >> Both Linux and FreeBSD map the EFI framebuffer as write-combining by >> default, so I assume (hope) that this is a safe change to make. > > No, an unaware Dom0 OS may not work correctly when the frame > buffer is WC. It also might come as a surprise to the Dom0 OS that > there is a WC range in one of the MTRRs where none would be > expected. Plus - why for EFI only? Because that's what other OSes did, but if it's not going to work... I can send a patch which we're currently using which sticks in a few process_pending_softirqs() in strategic places. -- Ross Lagerwall