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/
Home Products Support Community News


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

To: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] anomaly in irq check in fixup_page_fault()
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Thu, 21 Jul 2011 07:35:00 +0100
Delivery-date: Wed, 20 Jul 2011 23:36:05 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=00r570Wn0x5gaoXAVWTqF2a4WXyB6NntHtum+/sR0Jw=; b=A5MchN09m1jkd9xdV/YulmK47sxm8VSCnnG3O4AvVzJPgwp/Y+ijDLiQzEv5GQTswJ z4qHm4Q9HCMxklI3fuuyHSfbKnbTV9a9o6cWEjLyRJhcD4nRX5aYR+vDnEpwag4WUJcF yCiPK5ZbrUtmiyogdkvECegJyc51HBIF+IgNA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110720183002.56275d4b@xxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcxHcFCJelDH/3nKXkSZnvmZILvRpQ==
Thread-topic: [Xen-devel] anomaly in irq check in fixup_page_fault()
User-agent: Microsoft-Entourage/
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