Re: [Xen-devel] anomaly in irq check in fixup_page_fault()

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 21/07/2011 02:30, "Mukesh Rathor" <mukesh.rathor@xxxxxxxxxx> wrote:

> Hi,
> 
> This is a bit confusing. This for PVOPs kernel, I've not looked at older
> PV kernels to see what they do yet. But, the VCPU starts with
> evtchn_upcall_mask set and eflags.IF enabled. However, during kernel
> boot memory mapping lot of faults are getting fixed up by xen in:
> 
> fixup_page_fault():
>     /* No fixups in interrupt context or when interrupts are disabled. */
>     if ( in_irq() || !(regs->eflags & X86_EFLAGS_IF) )  <------
>         return 0;

A PV guest never has EF.IF=0, so the early exit should never be triggered by
a guest fault.

Your best bet is to fake this out in your HVM container wrapper. Just write
an EFLAGS into the saved regs that has EF.IF=1, as would always be the case
for a normal PV guest. Rather that than fragile eis_hvm_pv() checks
scattered around.

The setting of EF.IF shouldn't matter much for your guest as you'll be doing
PV event delivery anyway, but I wonder how it ends up with EF.IF=0 -- is
that deliberate?

 -- Keir

> The guest is running under the assumption of INTs disabled during
> init_memory_mapping, and the first enable happens much later. So this
> check seems redundant at least for PVOPs kernel.
> 
> Now for my hybrid, the guest during initial boot is running with IF
> disabled, so fixup doesn't like that. Not sure if permanently disabling
> the (eflags & X86_EFLAGS_IF) check for hybrid would be a good idea for
> me.
> 
> thanks,
> Mukesh
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel