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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> 08.07.09 09:43 >>>
>This patchset is an update for previous one to support memory add.
>
>The change includes 
>a) changes to boot allocator, frametable setup, m2p table setup, so that they 
>will be called not-only when system boot up, but also
>when hot add happens
>b) Changes to page fault handler, to propgate frametable/m2p table changes to 
>all guest.
>
>Comparing to previous patchset, the difference is:
>a) Rename the function name of boot allacator extension.
>b) Fix compatibility mode bugs. One is, we will not update the 
>m2p_compat_vstart if we support memory add. 

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).

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).

Jan


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