From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Question about PV guest accessing /dev/mem Date: Wed, 28 Jul 2010 07:49:14 +0100 Message-ID: References: <41885A88D9043444B138491FB10E15420496C7E674@azsmsx506.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <41885A88D9043444B138491FB10E15420496C7E674@azsmsx506.amr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Oehrlein, Scott" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 28/07/2010 02:37, "Oehrlein, Scott" wrote: > I can then read/write to the devices config space using logicaladdress. W= hen > using Xen=B9s PV functionality with pciback/pcifront to assign the device t= o the > guest on a platform without VT-d support, an attempt to use logicaladdres= s > results in the following error in ``xm dmesg=B9=B9: > =20 > (XEN) mm.c:1747:d23 Bad L1 flags 800000 > =20 > Does this mean Xen=B9s mmu is not mapping gfn to mfn correctly? Or what is > happening after the call to mmap that is different from native path? I think that means the guest OS is trying to map a PTE with the NX bit set when your processor does not support NX. Xen disallows that, and it would b= e a bug in the guest (Linux 2.6.34 in this case?). -- Keir