[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 2/2] xen: make available hvm_fep to non-debug build as well
On Fri, Jun 17, 2016 at 08:45:39AM -0600, Jan Beulich wrote: > >>> On 17.06.16 at 15:50, <andrew.cooper3@xxxxxxxxxx> wrote: > > On 17/06/16 12:05, Wei Liu wrote: > >> @@ -182,6 +183,28 @@ static int __init hvm_enable(void) > >> if ( !opt_altp2m_enabled ) > >> hvm_funcs.altp2m_supported = 0; > >> > >> + if ( opt_hvm_fep ) > >> + { > >> + unsigned int i, j; > >> + > >> + printk("**********************************************\n"); > >> + printk("******* WARNING: HVM FORCED EMULATION PREFIX IS > >> AVAILABLE\n"); > >> + printk("******* This option is *ONLY* intended to aid testing of > >> Xen.\n"); > >> + printk("******* It has implications on the security of the > >> system.\n"); > >> + printk("******* Please *DO NOT* use this in production.\n"); > >> + printk("**********************************************\n"); > >> + for ( i = 0; i < 3; i++ ) > >> + { > >> + printk("%u... ", 3 - i); > >> + for ( j = 0; j < 100; j++ ) > >> + { > >> + process_pending_softirqs(); > >> + mdelay(10); > >> + } > >> + } > > > > I would drop this 3s wait, and I plan to drop it from sync_console as > > well. It isn't of any practical use, even if you are watching the > > serial console on boot, and just leads to an unnecessary delay. Worse, > > the two delays are cumulative. > > I think the delay serves a purpose (for the messages to not scroll by > unnoticed), but I do appreciate that having two such delays is not > really desirable. Considering that I would also like these messages to > go into .init.rodata (also those for the sync_console warning), perhaps > worth a little bit of abstraction? > What is the plan here? Should I keep or remove the delay? Do you want me to refactor things? Wei. > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |