Re: [Xen-devel] [edk2] MMIO regions in GetMemoryMap ()0 (fwd)

[Parth Dixit <parth.dixit@xxxxxxxxxx>]

+xen dev list

On 24 February 2015 at 20:25, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Fri, 13 Feb 2015, Julien Grall wrote:
>> On 13/02/2015 11:44, Ard Biesheuvel wrote:
>> > On 13 February 2015 at 11:12, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
>> > >
>> > >
>> > > On 13/02/2015 10:29, Stefano Stabellini wrote:
>> > > >
>> > > > Hello all,
>> > > >
>> > > > Unfortunately Dong Wei was wrong about the possibility of using the 
>> > > > UEFI
>> > > > System Memory Map to retrieve the list of MMIO regions on the system, 
>> > > > as
>> > > > it could be lacking some.
>> > > >
>> > > > A possible alternative, suggested by Ian, would be to map MMIO regions
>> > > > into Dom0 on demand whenever Dom0 traps into Xen trying to read/write 
>> > > > to
>> > > > a page that is not normal memory. The page would be identified as
>> > > > belonging to an unadvertised MMIO region and mapped in the p2m at that
>> > > > point.
>> > >
>> > >
>> > > There is one issue with this solution. How do you know if you have to map
>> > > the MMIO region cache or uncached?
>> > >
>> >
>> > The UEFI spec mandates that the memory map describes all memory in the
>> > system, so if dom0 accesses any ranges outside of that, it makes sense
>> > to just use device mappings for stage 2.
>>
>> It's only describe RAM memory, right? If so, this doesn't cover cached PCI
>> bar.
>>
>> Maybe, Linux should ask explicitly to map the region?
>
> I don't think that device memory has a cacheability attribute, does it?
>
> I guess that those cacheable regions would have to be treated as normal
> memory and in any case if we map device memory as normal memory in
> stage2 and the guest maps it as device memory, the resultant type is
> device memory, as it should be.
>
> I don't think we have a problem here.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel