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] ioperm problem

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] ioperm problem
From: Ben Guthro <ben@xxxxxxxxxx>
Date: Thu, 17 Nov 2011 17:20:37 -0500
Cc: ja <pavel@xxxxxxxxxx>, Ben Guthro <ben.guthro@xxxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, tom.goetz@xxxxxxxxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Thu, 17 Nov 2011 14:21:25 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6wcln1NOdKZt9CHwhdTptE+zT+q64585HoZRwkmn39E=; b=AIV6uFpcjFzWarEV8lgBW9LRyJ7QNnKpIt7xEzPUJl4BdILWXGHgWqg0DJpnWLJv5p B7JxbQjG6PwdaFP39hTHKUBKJH+H8p+JrmyFT1BEDKJCey1rI2mQaWQWuLQEmAa3YQCv 2SnrjIbUwWBUFlJHw1oynShBYlZUjrhru/whE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4EC54D05.3050308@xxxxxxxx>
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>
References: <201111132219.07211.pavel@xxxxxxxxxx> <20111116145730.GA11502@xxxxxxxxxxxxxxxxxxx> <4EC51292.7000302@xxxxxxxxxxxxxxxxxxx> <20111117173010.GA3623@xxxxxxxxxxxxxxxxxxx> <4EC54D05.3050308@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Looking back through the bug database, the problem started in uvesafb,
while running in the nVidia closed source driver
The user reported very long boots, and I found the following repeated
over, and over in the syslog:

Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 29.677547] uvesafb:
Getting mode info block for mode 0x106 failed (eax=0x4f01, err=1)
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 29.685667] v86d[363]
general protection ip:7f0acfdbdb43 sp:7fff100d3748 error:0 in
libx86.so.1[7f0acfdb6000+1f000]

This continues every 5s until:

Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.677745] uvesafb:
Getting mode info block for mode 0x161 failed (eax=0x4f01, err=1)
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.692267] uvesafb:
VBIOS/hardware doesn't support DDC transfers
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.692275] uvesafb: no
monitor limits have been set, default refresh rate will be used
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.692369] v86d[396]
general protection ip:7ff77908bb43 sp:7fffa8b7e708 error:0 in
libx86.so.1[7ff779084000+1f000]


Chasing this down, I found it all started from drivers/video/uvesafb.c: 506:

uvesafb_reset(task);
task->t.regs.eax = 0x4f01;
task->t.regs.ecx = (u32) *mode;
task->t.flags = TF_BUF_RET | TF_BUF_ESDI;
task->t.buf_len = sizeof(struct vbe_mode_ib);
task->buf = par->vbe_modes + off;

err = uvesafb_exec(task);
if (err || (task->t.regs.eax & 0xffff) != 0x004f) {
printk(KERN_WARNING "uvesafb: Getting mode info block "
"for mode 0x%x failed (eax=0x%x, err=%d)\n",
*mode, (u32)task->t.regs.eax, err);
mode++;
par->vbe_modes_cnt--;
continue;
}

(the same code also exists in testvbe.c - line 55)

This executes in the v86d userspace process
v86d/v86_common.c:
int v86_task(struct uvesafb_task *tsk, u8 *buf)


uvesafb was executing the video BIOS code, as mapped in /dev/mem


However, it was unable to access the ioport, causing a GPF.

uvesafb would loop on that, with a sleep(5)

The end result was a colossally long boot process seen by the end user.



The (albeit hacky) solution to open up the VGA ioports resolved the
seemed hang on this older nVidia card.



Hope this explanation make some semblance of sense.


/btg


On Thu, Nov 17, 2011 at 1:05 PM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>
> On 11/17/2011 09:30 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 17, 2011 at 08:56:34AM -0500, Ben Guthro wrote:
> >> Attached is our patch to work around issues with the ioports with
> >> some older nVidia cards.
> >>
> >> This, admittedly is a bit of a hack, and not exactly something that
> >> I would see upstream wanting to carry, for a variety of reasons. It
> >> really should all be predicated on whether the kernel is the initial
> >> domain, etc.
> >>
> >> This opens up the legacy VGA ports in the VGA arbiter code.
> > Was there a userspace program that did this? As in it would
> > call ioperm?
> >
> >> Konrad - I think that you had suggested an alternate way of doing
> >> this, IIRC, but I can't seem to find it in my inbox. Due to
> >> competing demands, and my nVidia hardware disappearing, I never went
> >> back to rework this code.
> > Ah, I might have some code that I just uncovered from Jeremy's old
> > git tree.
> >
> > I've put it up on devel/ioperm - it nicely wraps the ioperm
> > call to go the native or paravirt.
>
> Yeah, I'd sort of let that sit, since there's nothing in a "modern"
> system which should require it.  Allowing usermode to poke at ioports
> from within a domain is inherently suspect, after all.
>
>    J
>
> _______________________________________________
> 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

<Prev in Thread] Current Thread [Next in Thread>