[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 20.06.16 at 11:09, <wei.liu2@xxxxxxxxxx> wrote: > 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? I didn't see a response from Andrew yet; I continue to think some delay ought to be there. > Should I keep or remove the delay? Do you want me to refactor things? If you're up to some refactoring, that'd be appreciated. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |