Xen devel - Jan 2012 - [Ques]:xen_ident_map_ISA ant it's mfns...

Hi,

I am bit confused about the do_update_va_mapping call that dom0 makes in
xen_ident_map_ISA() to map ffff8800000a0000 to mfn a0. The mfn belongs
to DOMID_IO. Before the mfn is mapped, the l1 entry is not empty:

0000000139d08500:  00100001380a0027

After the mapping:

0000000139d08500:  00100000000a0467  as expected.

However, the mfn 1380a0 still seems to belong to dom0. Shouldn''t that
have been returned back to the xen heap? 

thanks,
Mukesh

On Fri, Jan 20, 2012 at 05:29:32PM -0800, Mukesh Rathor
wrote:
> Hi,
> 
> I am bit confused about the do_update_va_mapping call that dom0 makes in
> xen_ident_map_ISA() to map ffff8800000a0000 to mfn a0. The mfn belongs
> to DOMID_IO. Before the mfn is mapped, the l1 entry is not empty:
> 
> 0000000139d08500:  00100001380a0027
> 
> After the mapping:
> 
> 0000000139d08500:  00100000000a0467  as expected.
> 
> However, the mfn 1380a0 still seems to belong to dom0. Shouldn''t
that
> have been returned back to the xen heap? 
It should if dom0 had returned it back. The setup.c code you where
it returns the swatches of memory has a check where it decides to return
only memory above 1M. The <1MB is left unused.

In other words, we make all the PTE''s to the look as if PFN are
1:1 to MFN. But if you do a MFN lookup to PFN (mfn_to_pfn) for the regions below
1MB, you end up getting PFNs that are _not_ in the 1MB region.
Instead they are just normal memory.

There is a good reason for this, which if I remeber right is to allow
fixmap to work correctly, but if you are using ioremap it would return
empty RAM so that most of the PnP devices (like RTC) would not load.

hmm, I think so . I remember thinking to remove that once (so allow the
<1MB region to be freed), and I hit some pretty big problems.

Is there a particular reason you want to "Free" that memory?
> 
> thanks,
> Mukesh
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

On Mon, 23 Jan 2012 12:43:17 -0400
Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> On Fri, Jan 20, 2012 at 05:29:32PM -0800, Mukesh Rathor wrote:
> > Hi,
> > 
> > I am bit confused about the do_update_va_mapping call that dom0
> > makes in xen_ident_map_ISA() to map ffff8800000a0000 to mfn a0. The
> > mfn belongs to DOMID_IO. Before the mfn is mapped, the l1 entry is
> > not empty:
> > 
> > 0000000139d08500:  00100001380a0027
> > 
> > After the mapping:
> > 
> > 0000000139d08500:  00100000000a0467  as expected.
> > 
> > However, the mfn 1380a0 still seems to belong to dom0.
Shouldn''t
> > that have been returned back to the xen heap? 
> 
> It should if dom0 had returned it back. The setup.c code you where
> it returns the swatches of memory has a check where it decides to
> return only memory above 1M. The <1MB is left unused.
> 
> In other words, we make all the PTE''s to the look as if PFN are
> 1:1 to MFN. But if you do a MFN lookup to PFN (mfn_to_pfn) for the
> regions below 1MB, you end up getting PFNs that are _not_ in the 1MB
> region. Instead they are just normal memory.
> 
> There is a good reason for this, which if I remeber right is to allow
> fixmap to work correctly, but if you are using ioremap it would return
> empty RAM so that most of the PnP devices (like RTC) would not load.
> 
> hmm, I think so . I remember thinking to remove that once (so allow
> the <1MB region to be freed), and I hit some pretty big problems.
> 
> Is there a particular reason you want to "Free" that memory?
I am not trying to "free" it. It just occured to me the old frames are
never used, 1380a0 in the above case.

thanks,
Mukesh