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

RE: [Xen-devel] [patch] more correct pfn_valid()


  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Scott Parish" <srparish@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Thu, 19 May 2005 10:14:06 +0100
  • Delivery-date: Thu, 19 May 2005 09:13:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcVb9aZ7Rlj1GNpbTJqBIcUW7A2ChAAANsGgAAkVbyAACQmCUAAAqYiQAADuuCAAAHE4wAAA0NrwAAAvHuAAAFFFUAABmb1g
  • Thread-topic: [Xen-devel] [patch] more correct pfn_valid()

> Thanks and that's make it clearer now. So just for last 
> confirmation (sorry for tedious):
>       1. If driver domN's 'physical' memory is set as 0 - 4G 
> continuously, and
>       2. When dom0 does PCI bus init, machine mmio space is 
> set between [3G, 3G+512M] (Take a large range for example),
> 
> Under above 2 conditions, current paravirtualized 
> implementation can clearly handle between:
>       1. A normal access to 'physical' 3G + 4k address, and
>       2. Access to machine mmio address 3G + 4k of some 
> physical device
> 
> Is that assumption right? 

Yes, that's it.

> BTW, will that make some 
> complexities for non-access operation, like comparison upon 
> some address?

Linux doesn't do this (It doesn't make sense anyhow).

Ian

_______________________________________________
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®.