Re: [Xen-devel] [PATCH v2 2/2] xen: make available hvm_fep to non-debug build as well

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Jun 20, 2016 at 04:11:31AM -0600, Jan Beulich wrote:
> >>> 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.
> 

OK. I will give Andrew a chance to reply.

> > 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.
> 

Sure. I think I can factor out a "warning" infrastructure (just an array
to keep track of all warning texts,  a function to add text to the array
and a function to print out all the added warnings).

Wei.

> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel