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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>-----Original Message-----
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: Thursday, May 19, 2005 4:23 PM
>To: Tian, Kevin
>
>On 19 May 2005, at 09:14, Tian, Kevin wrote:
>
>> For this part, I made a mistake to confuse domN and dom0. OK, for
>> paravirtualized guest, there's actually no I/O range for domN, since
>> the
>> front driver in domN will do all things to communicate with backend
in
>> Dom0. But what about a driver domain which has access to physical
>> device, thus need real I/O address?
>
>We rely on the driver using the dma_coherent/pci_consistent/bus_address
>macros for mapping device memory. Originally designed to handle IOMMUs,
>it is handy for us to determine places where code is handling real
>machine physical addresses rather than pseudophysical addresses. This
>gets groans of distaste from the kernel maintainers but has worked
>enormously well so far (AGP needed patching separately though).
>
>  -- Keir

Thanks for guide. That's really a way to differentiate normal memory and
machine memory used for device. After searching the source tree, yes, if
all drivers conform to this convention (should be), low level pci-dma
interface can adjust guest pfn -> machine pfn mapping to promise
contiguous requirement in machine address layer, and also 4G limitation
for old DMA driver on new platform. 

But, this only handles the difference between machine memory and
'physical' memory, not the one between "physical' memory and machine
MMIO space. If 'physical' memory is kept continuous whatever memory size
is, there'll be some overlap with machine MMIO space anyway. But since
your careful design can promise no confusion, then let it since there're
already many mixed knowledge in dear paravirtualized domain. :)

Thanks,
Kevin



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