Re: Where is netbsd-XEN3_DOM0.gz

[Roger Pau Monné <roger.pau%entel.upc.edu@localhost>]

On Fri, Jun 22, 2018 at 3:07 PM, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> D'Arcy Cain <darcy%NetBSD.org@localhost> writes:
>
>> On 2018-06-21 09:03 PM, Greg Troxel wrote:
>>>> Obviously no need for AGP.
>>>
>>> True, and no need for a vast array of things - basically all video, all
>>> sound.
>>
>> I'm just saying that Xen servers aren't a good choice for a gaming
>> machine, at least not in the DOM0.
>
> But that's not the question.
>
> If someone has a box that works for whatever graphics they want, then
> running it as a dom0 instead of bare is a reasonable thing to do.  That
> enables also running a domU.  Right now this is not feasible for some
> because of the agp bug (and harder for those that don't have the bug,
> because of the workaround), and it's suboptimal due to not having SMP.
>
>>> I wonder if anyone has tested with netbsd-8 or -current, and with Xen
>>
>> I stumbled on this issue on a current box.
>
> That's good to know; would be good to drop that in the PR (just the
> versions of xen and netbsd).
>
>
> I saw your commit - it would be nice to leave the agp line in, commented
> out, and have a comment with the PR.  While we've been getting "booting
> with agp fails" reports, I suspect we'll now get "agp doesn't attach"
> reports from some subset of the currently-uncounted multitudes who are
> running the XEN3_DOM0 kernel without running into this bug.

Looking at the log from Xen:

 agp0 at pchb0: i965-family chipset
 (XEN) mm.c:912:d0 pg_owner 0 l1e_owner 0, but real_pg_owner -1
 (XEN) mm.c:983:d0 Error getting mfn 100 (pfn ffffffffffffffff) from
L1 entry 8000000000100017 for l1e_owner=0, pg_owner=0
 xpq_flush_queue: 1 entries (0 successful) on cpu0 (0)
 cpu0 (0):
   0x00000000af043c78: 0x8000000000100017
  kpm_pdir[0]: 0xab009027
 panic: HYPERVISOR_mmu_update failed, ret: -16

It seems like NetBSD is trying to map MFN 0x100, which is the first
RAM page after the low 1MB according to the memory map reported by Xen
(in the same log):

 (XEN) Xen-e820 RAM map:
 (XEN)  0000000000000000 - 000000000009fc00 (usable)
 (XEN)  000000000009fc00 - 00000000000a0000 (reserved)
 (XEN)  00000000000e4000 - 0000000000100000 (reserved)
 (XEN)  0000000000100000 - 00000000af790000 (usable)  <--- MFM 0x100
lives in this RAM region
 (XEN)  00000000af790000 - 00000000af79e000 (ACPI data)
 (XEN)  00000000af79e000 - 00000000af7e0000 (ACPI NVS)
 (XEN)  00000000af7e0000 - 00000000af800000 (reserved)
 (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
 (XEN)  00000000ffb00000 - 0000000100000000 (reserved)

Xen treats the memory below 1MB specially:

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/mm.c;h=2b743921c3ac1dfb340146ac4563ecb571dfa07d;hb=HEAD#l300

In order to allow Dom0 to map whatever is there (BDA, EBDA, VGA
MMIO...). But 0x100 is normal RAM, and Dom0 shouldn't attempt to
access it unless it's assigned to it, which seems like it's not the
case in the example above.

It seems to me like there's an error in NetBSD AGP driver, it
shouldn't attempt to map 0x100, or otherwise there's an error in your
firmware that reports 0x100 as usable RAM when it's instead a MMIO
region used by AGP.

Maybe there's an off-by-one in the AGP driver that it attempts to map
0x100 when it should map up to 0xff?

Roger.