Re: port-xen/52016: Mismatch between mem_clusters and pmap_enter bounds check

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

The following reply was made to PR port-xen/52016; it has been noted by GNATS.

From: John Nemeth <jnemeth%cue.bc.ca@localhost>
To: gnats-bugs%NetBSD.org@localhost, port-xen-maintainer%netbsd.org@localhost,
        gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, coypu%sdf.org@localhost
Cc: 
Subject: Re: port-xen/52016: Mismatch between mem_clusters and pmap_enter bounds check
Date: Wed, 1 Mar 2017 08:44:12 -0800

 On Mar 1, 11:15am, Manuel Bouyer wrote:
 }
 } The following reply was made to PR port-xen/52016; it has been noted by GNATS.
 } 
 } From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 } To: coypu%SDF.ORG@localhost
 } Cc: gnats-bugs%NetBSD.org@localhost, port-xen-maintainer%netbsd.org@localhost
 } Date: Wed, 1 Mar 2017 12:13:10 +0100
 } 
 }  On Wed, Mar 01, 2017 at 09:55:40AM +0000, coypu%SDF.ORG@localhost wrote:
 }  > On Wed, Mar 01, 2017 at 09:35:01AM +0000, Manuel Bouyer wrote:
 }  > >  AFAIK X11 uses /dev/mem to access the hardware.
 }  > >  
 }  > 
 }  > Huh, so it does.
 }  > I guess X doesn't currently fail because it's already mapped
 }  > by the boot process, so no fault and no trip to pmap_enter?
 }  
 }  No, it works because the hypervisor allows mapping the video
 }  harware address. I don't know why it rejects the addresses used by dmidecode
 
      I haven't done a deep dive, but based on comments here and
 elsewhere, it is likely that dmidecode is trying to access the
 "BIOS ROM" and in PV mode there is no BIOS.  We need a way for
 mappings done via /dev/mem to fail gracefully (i.e. not panic the
 system).
 
 }-- End of excerpt from Manuel Bouyer