Question about PV guest accessing /dev/mem

Question about PV guest accessing /dev/mem

[Oehrlein, Scott]

[-- Attachment #1.1: Type: text/plain, Size: 1026 bytes --]

Hi all,

I am wondering if someone can explain to me the process involved when accessing MMIO from a PV guest via /dev/mem. In a native (non-VT) environment, if I take the BAR0 address of my device and perform the following two lines of code:

fd = fd = open("/dev/mem", O_RDWR);
logicaladdress = (unsigned long) mmap(NULL, (memoryspan + pagesize), PROT_READ|PROT_WRITE, MAP_SHARED, fd, (off_t)physicaladdress);

I can then read/write to the devices config space using logicaladdress. When using Xen's PV functionality with pciback/pcifront to assign the device to the guest on a platform without VT-d support, an attempt to use logicaladdress results in the following error in ``xm dmesg'':

(XEN) mm.c:1747:d23 Bad L1 flags 800000

Does this mean Xen's mmu is not mapping gfn to mfn correctly? Or what is happening after the call to mmap that is different from native path?

Any insight would be appreciated. I'm using Xen 4.0 2.6.32.16 PVOPS dom0 and 2.6.34 domU from konrad's repository.

Thanks,
Scott


[-- Attachment #1.2: Type: text/html, Size: 3368 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Question about PV guest accessing /dev/mem

[Keir Fraser]

On 28/07/2010 02:37, "Oehrlein, Scott" <scott.oehrlein@intel.com> wrote:

> I can then read/write to the devices config space using logicaladdress. When
> using Xen¹s PV functionality with pciback/pcifront to assign the device to the
> guest on a platform without VT-d support, an attempt to use logicaladdress
> results in the following error in ``xm dmesg¹¹:
>  
> (XEN) mm.c:1747:d23 Bad L1 flags 800000
>  
> Does this mean Xen¹s 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 be
a bug in the guest (Linux 2.6.34 in this case?).

 -- Keir