[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Trapping I/O accesses of a driver domain


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Olatunji Ruwase" <oor@xxxxxxxxxx>
  • Date: Thu, 10 Nov 2011 22:25:56 -0500 (EST)
  • Delivery-date: Thu, 10 Nov 2011 19:26:54 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

>> Xen-3.3 with a dom0 and driver domU both running linux-2.6.18-xen. For
>> various reasons HVM Xen is not suitable for my work.
>
> Um, why not use something more recent. Like Ubuntu or Fedora Core 16?
>
 My work is based on simulated hardware logging and a significantly
 modified FC5, porting the kernel modifications to FC6 is significantly
 than to more recent kernels like FC16.

>> ioremap'd pages, this seems pretty straightforward since the ptes are
>> marked with _PAGE_IO before they are passed to Xen. And so it seems
>
> Not all the time and it is not a requirement.
>
 I am happy to modify the 2.16.8-xen to cover the outstanding cases,
 except this is a fundamentally flawed approach. Can you elaborate the
 ioremap scenarios for pte are not marked _PAGE_IO. Are the requirements
 documented?

>> modifying do_mmu_update () to detect and mark such ptes not present
>> should work. Is this a reasonable approach ?.
>
> What about just checking the MFNs against the ones in the E820 that
> are in the PCI gap space?
>>
  I m not familiar with E820, but will explore it, thanks.

>>  hypercall informing Xen that the locations are used for I/O. I am
>> probably
>
> Right.
>

 Thanks for the response.

tunji


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.