Re: [Xen-devel] ioperm problem

[Ben Guthro <ben@xxxxxxxxxx>]

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