Re: [Xen-devel] Xen with dom0 pvops on ultra-recent "git tip" kernel on x86_64

[Christophe Saout <christophe@xxxxxxxx>]

Hi,

> > I haven't been brave enough to even attempt starting X; there's a lot of 
> > work to be done if you want to do anything beyond dumb framebuffer.
> > 
> > Anyway, in this case, I definitely haven't added this call, so it will 
> > need to be done somewhere.  Does it need to be called once at startup, 
> > or on every context switch?  There may well be a suitable place to hook 
> > this into already, but we can add a new pvop if its really needed.
> 
> Just to let you know.  I have this very preliminary, incomplete (x86_32
> parts are missing) and barely tested patch (barely tested under Xen, not
> checked if the native stuff works).  It seems to work on my test case,
> with a program where I ioperm some I/O range and try to inb() some bytes
> from it (segfaults when it should and/or returns values when it should),
> and it also survives context switches.

Eheh, while trying with gdb I found out that context switches do not
restore the bitmap correctly.  Guess what, two obvious and stupid
bugs. :-)  in enlighten.c:xen_set_io_bitmap it has to say "thread->"
instead of "current->thread." and in process_64.c the call has to pass
the "next" variable and not the "next_p" to set_io_bitmap (the thread,
not the task).  Then context switches actually do seem to work.

> However, the X server is now giving me a "Corrupted page table", which I
> caught on netconsole and I have no clue how I should debug that one.

Just checked, the machine isn't dead, just screen and keyboard, ssh
continues to work.  So, gdb'd it from ssh, and also removed the call to
"pgtable_bad" in arch/x86/mm/fault.c (which is triggered by the RSVD bit
being set on the page table, hmmmmm), so I get a segfault which gdb can
catch.

Ok, the X server first spits a strange message:
 (EE) RADEON(0): V_BIOS address 0x22c0 out of range
instead of
 (II) RADEON(0): Primary V_BIOS segment is: 0xc000
(in xf86int10GetBiosSegment)

and the later dies in the radeon driver with the bad memory / pagetable
access in radeon_card_posted() in what seems to be the fast attempt to
do an access to the card's MMIO area.

That base address of that one seems to be obtained by libpciaccess,
which, as far as I understand, digs around in /sys to get the relevant
PCI data and then maps it into memory, so I guess it is not related to
the warning message about the V_BIOS address.

I guess that X server is one of the few processes that try to map PCI
hardware MMIO ranges into memory, so perhaps there is also something
missing (especially since it triggers acceses to pages with the RSVD bit
set, something which should never happen under normal circumstances, if
I understand correctly).

Cheers,
        Christophe



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