[Xen-devel] RE: [PATCH v2.0 0/6] Add memory add support to Xen

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

Keir Fraser wrote:
> On 10/07/2009 08:16, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
> 
>> There's one other problem with this overall change: Non-pv-ops pv
>> Linux guests (all versions afaict) establish an upper bound on the
>> m2p table size during early boot, and use this to bound check MFNs
>> before accessing the array (see the setup and use of
>> machine_to_phys_order). Hence, when you grow the m2p table, you
>> might need to send some sort of notification to all pv domains so
>> that they can adjust that upper bound. If not a notification, some
>> other communication mechanism will be needed (i.e. a new ELF note).
>> Hot-added memory must never be made visible to a pv guest not
>> supporting this new protocol (in particular, hot add may need to be
>> disabled altogether if Dom0 doesn't support it). 
> 
> The correct answer I think is for Xen to specify a
> machine_to_phys order
> that corresponds to the size of the M2P 'hole' rather than to the
> actual amount of memory currently populated on this host. The extra

>From the hypercall of XENMEM_machphys_mapping, seems it return the m2p hole 
>already (I mean non-compat guest), so why it is "actual amount of memory"?

    case XENMEM_machphys_mapping:
    {
        static const struct xen_machphys_mapping mapping = {
            .v_start = MACH2PHYS_VIRT_START,
            .v_end   = MACH2PHYS_VIRT_END,
            .max_mfn = MACH2PHYS_NR_ENTRIES - 1
        };

        if ( copy_to_guest(arg, &mapping, 1) )
            return -EFAULT;

        return 0;
    }

Thanks
Yunhong Jiang


> inefficiency is only that some I/O MFNs may be detected via fault
> rather than out-of-bounds check (and then probably only on systems
> with <4G RAM). 
> 
> This for x86/64 guests of course. We already established that compat
> guests and memory add are going to have lesser mutual support.
> 
> -- Keir
> 
>> As to pv-ops currently not being affected by this - the respective
>> check currently sits in an #if 0 conditional, but certainly this is
>> a latent bug (becoming a real one as soon as Dom0 or device
>> pass-through come into the picture): Since without the check
>> unbounded MFNs can be used to index into the array, it is possible
>> to access I/O memory here, so simply being prepared to handle a
>> fault resulting from an out-of-bounds access isn't enough. The
>> minimally required boundary check is to make sure the resulting
>> address is still inside hypervisor space (under the assumption that
>> the hypervisor will itself never make I/O memory addressable for the
>> guest).  
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel