Re: X server in dom0: Bad VBT signature

["Cherry G. Mathew" <cherry.g.mathew%gmail.com@localhost>]

On 2 September 2012 18:48, Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
wrote:
...

>> >> Index: arch/x86/x86/pmap.c
>> >> ===================================================================
>> >> RCS file: /cvsroot/src/sys/arch/x86/x86/pmap.c,v
>> >> retrieving revision 1.178
>> >> diff -u -r1.178 pmap.c
>> >> --- arch/x86/x86/pmap.c       15 Jun 2012 13:53:40 -0000      1.178
>> >> +++ arch/x86/x86/pmap.c       2 Sep 2012 07:32:29 -0000
>> >> @@ -985,7 +985,12 @@
>> >>       else
>> >>               pte = kvtopte(va);
>> >>  #ifdef DOM0OPS
>> >> -     if (pa < pmap_pa_start || pa >= pmap_pa_end) {
>> >> +     if (xen_dom0_pa_isa_conflict(pa)) { /* dom0 wants to access ISA mem,
>> >> not ram */
>> >> +             /*
>> >> +              * This is a hack. The right thing to do would be to
>> >> +              * have bus_space_map() et al. manage the p2m/m2p
>> >> +              * tables.
>> >
>> > I don't understand what you mean here; bus_space_map() already properly
>> > calls pmap_enter_ma() with a machine address.
>> > This problem only exists for userland accessing devices through /dev/mem,
>> > because we want /dev/mem to map both physical or machine addresses,
>> > depending on what the caller means. The right fix would be to have a
>> > way to express the address space at this level. But this is intrusive.
>> >
>>
>> yep, I was thinking of a ioctl() initially.
>>
>> I mulled this over a bit, and seeing as you say that only userland is
>> involved, we probably don't need to fit it to bus_space_map()
>>
>> What I mean is:
>> On xen we have ma, pa tuples that are managed by the p2m/m2p tables.
>> The way we export the translation to lookups is via xen specific
>> functions in xenpmap.h
>> We also need to maintain aliased pmap_kenter/extract_pa() et. al
>> symbols between pmap.c and xen_pmap.c
>>
>> We also seem to need to export pmap_kenter_ma() and pmap_enter_ma()
>> which are xen abstractions to native code.
>> I was wondering if it's possible to further cleanly separate the
>> xen/native cases.
>>
>> > Another problem with your patch is that you don't prevent the memory in
>> > range pa < 0x100000 from being used by UVM. So you'll end up with
>>
>> Should I have used: IOM_BEGIN/END instead ?
>
> that won't help: for xen, the available RAM range passed to UVM
> is 0 -> pmap_pa_end (pa_start is, or close to 0, if I remember properly).
> All adresses in this range are assumed to be physical addresses.
> If you want to use part of this range for something that is not RAM,
> you need to exclude this range from the memory map passed to UVM.
> See uvm_page_physload() calls in i386 and amd64 machdep.
>

Yeah but that won't solve the abstraction problem, will it ? If we
skip the pa address space that needs to pass through to native, we
lose the RAM allocated there. Alternatively we can muck with the
p2m/m2p tables by remapping them elsewhere, *sigh*.

> And I'm not sure the addresse X wants to map are in the ISA hole.
> it may be in PCI memory space too, I guess.
>

I'm curious about this - currently we just assume that everything
above allocated RAM is meant for mem i/o.


>>
>> > regular pages mapped in device's memory space, which will likely lead to
>> > panic or spontaneous reboot.
>> >
>>
>> Will the following fix that: (I know your original code just removed
>> the uvm management of that range entirely, I'm just looking for an
>> alternative implementation)
>
> No, this has nothing to do with bus_space. I guess the memory addresses
> that X wants to use are never seen by bus_space, because no driver
> claims them.
>

I thought I saw a bus_space_mmap() somewhere in the uvm mmap codepath,
maybe I'm confused.

Perhaps it should be in a future /dev/xf86 driver mmap path.

-- 
~Cherry