xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* [Ques]:xen_ident_map_ISA ant it's mfns...
@ 2012-01-21  1:29 Mukesh Rathor
  2012-01-23 16:43 ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 3+ messages in thread
From: Mukesh Rathor @ 2012-01-21  1:29 UTC (permalink / raw)
  To: Xen-devel@lists.xensource.com

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Ques]:xen_ident_map_ISA ant it's mfns...
  2012-01-21  1:29 [Ques]:xen_ident_map_ISA ant it's mfns Mukesh Rathor
@ 2012-01-23 16:43 ` Konrad Rzeszutek Wilk
  2012-01-24  2:14   ` Mukesh Rathor
  0 siblings, 1 reply; 3+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-01-23 16:43 UTC (permalink / raw)
  To: Mukesh Rathor; +Cc: Xen-devel@lists.xensource.com

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Ques]:xen_ident_map_ISA ant it's mfns...
  2012-01-23 16:43 ` Konrad Rzeszutek Wilk
@ 2012-01-24  2:14   ` Mukesh Rathor
  0 siblings, 0 replies; 3+ messages in thread
From: Mukesh Rathor @ 2012-01-24  2:14 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk; +Cc: Xen-devel@lists.xensource.com

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-01-24  2:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-21  1:29 [Ques]:xen_ident_map_ISA ant it's mfns Mukesh Rathor
2012-01-23 16:43 ` Konrad Rzeszutek Wilk
2012-01-24  2:14   ` Mukesh Rathor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).