WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <keir.xen@xxxxxxxxx>
Subject: Re: [Xen-devel] anomaly in irq check in fixup_page_fault()
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Fri, 22 Jul 2011 08:39:09 +0100
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 22 Jul 2011 00:40:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA4D8724.1E48E%keir.xen@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <CA4D8724.1E48E%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-07-21 at 07:35 +0100, Keir Fraser wrote:
> 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.

When I was playing with PV in HVM prototypes way back I noticed that,
for a pvops kernel at least, we seem to accidentally rely on the fact
that trying to clear EFLAGS.IF from RING>0 silently ignores the change
(as it does for any privileged bits in EFLAGS). This meant that on
vmexit I would sometimes discover that IF was cleared. Originally I made
this shoot the guest (it must be misbehaving, right!) but in the end I
decided to be pragmatic and always |=EFLAGS_IF on the vmexit path.

I _think_ this was the original reason I discovered the issue that I
fixed with the short series I reposted at
http://marc.info/?l=linux-kernel&m=130987084009107 (IOW I think
kernel_eflags ended up with IF incorrect under pvops Xen, but it was a
long time ago so perhaps I'm misremembering).

I also vaguely recall that the optimisation used in Xen's implementation
of the xen_save_fl or xen_save_fl_direct, which basically only
guarantees that the bit at EFLAGS_IF is valid in the value it returns
(compared with native_save_fl which returns a full set of EFLAGS), was
also something I suspected being implicated in IF getting turned off --
but you can pretty easily (at the expense of the optimisation) make
those hooks return the real eflags with the ~evtchn_upcall_mask in the
EFLAGS_IF bit.

At the time I sprinkled assertions around the guest kernel to help debug
the issue, patch (against 2.6.32, so ancient) attached FWIW.

Ian.

> 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

Attachment: instrumentation.patch
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>