WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [GIT PULL] Small Xen bugfixes

On Sun, 2010-10-31 at 16:28 +0000, Jeremy Fitzhardinge wrote:
> On 10/31/2010 02:13 AM, Ian Campbell wrote:
> >> The 3rd is certainly simplest, at the cost of wasting a trivial amount
> >> of memory.
> > Doesn't Linux avoid using the lowest 1M anyway? (obviously apart from
> > the start of day probing for firmware tables etc).
> 
> No, it tries to use most of it I think.  It will tend to avoid the low
> 64k (maybe more) to avoid BIOS bugs.

It'll be interesting to see what effect Vista's avoidance of the whole
region (so I hear) has on BIOS vendors... (I think we can all guess)

> >>   Unfortunately it crashes early.  Sigh, will try and sort it
> >> out this afternoon.
> > Strange!
> 
> I didn't get a chance to poke at it again, but in retrospect, I think
> there are various "must succeed" allocations in low memory.  We don't
> need those allocations (things like AP boot trampoline, etc), but we
> don't bother to stub them out or prevent them from happening.  Reducing
> the system to one with *no* allocatable memory below 1M is just too
> strange, and would be a continuous source of problems in the future.

Agreed, we should try and mimic native as far as possible in this regard
or I fear we will see a never ending stream of little quirks and
oddities related to this sort of thing.

> Of the other two options, I think your original approach is going to be
> simplest.  E820 gap filling wouldn't be too bad, but we'd end up having
> to add a bit of gap-tracking logic to the E820 loop which isn't
> currently there.

It would also make us susceptible to perhaps being a bit fragile in the
face of unexpectedly insane e820s coming from the BIOS.

> Ignoring sub-1M gaps is simpler (and it needn't be
> conditional on xen_initial_domain(), because we would never expect to
> see anything strange sub-1M in a domU, and if there is, we should still
> be careful of it in case something odd is going on).

Absolutely.

I wonder if we shouldn't also do the following (note: untested). Since
Xen avoids using the sub-1M region for anything I think it is reasonable
to give the whole lot over to domain 0 for the purposes of finding
firmware table stashed in odd locations etc.

Ian.

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index ebb74ec..ab086e5 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2321,7 +2321,7 @@ __init void xen_ident_map_ISA(void)
 
        xen_raw_printk("Xen: setup ISA identity maps\n");
 
-       for (pa = ISA_START_ADDRESS; pa < ISA_END_ADDRESS; pa += PAGE_SIZE) {
+       for (pa = 0; pa < ISA_END_ADDRESS; pa += PAGE_SIZE) {
                pte_t pte = mfn_pte(PFN_DOWN(pa), PAGE_KERNEL_IO);
 
                if (HYPERVISOR_update_va_mapping(PAGE_OFFSET + pa, pte, 0))



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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Re: [GIT PULL] Small Xen bugfixes, Ian Campbell <=