Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID

[Tim Deegan <tim@xxxxxxx>]

(oops, seem to have dropped Mukesh from CC)

At 12:14 +0100 on 04 May (1336133690), Tim Deegan wrote:
> At 11:53 +0100 on 04 May (1336132407), Ian Campbell wrote:
> > > I'm not aware of anything deliberately tinkering with EFLAGS_ID,
> > 
> > I couldn't find any use other than the definition, although it maybe
> > open coded somewhere.
> 
> Looks like maybe it's the absence of it that we should worry about:
> Mukesh, can you try the attached patch?
> 
> > > but
> > > it's possible that vm86 interacts with it (of that we accidentally lose
> > > some parts of EFLAGS in emulation).
> > 
> > Yeah, but I can't figure out why hybrid dom0 would change that...
> 
> Indeed.  I'd expect this to fail for the same kernel in normal HVM.
> Maybe there's some difference in how the segment state is set up
> 
> Tim.

> diff -r 8f556a70ae0b xen/arch/x86/x86_emulate/x86_emulate.c
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c  Thu May 03 17:21:09 2012 +0100
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c  Fri May 04 12:13:55 2012 +0100
> @@ -372,6 +372,7 @@ typedef union {
>  #define CR4_TSD   (1<<2)
>  
>  /* EFLAGS bit definitions. */
> +#define EFLG_ID   (1<<21)
>  #define EFLG_VIP  (1<<20)
>  #define EFLG_VIF  (1<<19)
>  #define EFLG_AC   (1<<18)
> @@ -424,7 +425,7 @@ typedef union {
>   * These EFLAGS bits are restored from saved value during emulation, and
>   * any changes are written back to the saved value after emulation.
>   */
> -#define EFLAGS_MASK (EFLG_OF|EFLG_SF|EFLG_ZF|EFLG_AF|EFLG_PF|EFLG_CF)
> +#define EFLAGS_MASK (EFLG_OF|EFLG_SF|EFLG_ZF|EFLG_AF|EFLG_PF|EFLG_CF|EFLG_ID)
>  
>  /* Before executing instruction: restore necessary bits in EFLAGS. */
>  #define _PRE_EFLAGS(_sav, _msk, _tmp)                           \

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


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