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

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

  • To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>, "Scott Parish" <srparish@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Thu, 19 May 2005 16:56:01 +0800
  • Delivery-date: Thu, 19 May 2005 08:55:39 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-topic: [Xen-devel] [patch] more correct pfn_valid()

>-----Original Message-----
>From: Ian Pratt [mailto:m+Ian.Pratt@xxxxxxxxxxxx]
>Sent: Thursday, May 19, 2005 4:20 PM
> > 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?
>This works the same in dom0 and other domains:
>IO machine addresses must be mapped into the kernel virtual address
>space before you can use them. They are totally orthogonal to ram
>addresses, and don't get mfn->pfn translated.

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

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

Thanks a lot, 
- Kevin

Xen-devel mailing list



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