At 10:46 +0100 on 26 May (1274870761), Keir Fraser wrote:
> On 26/05/2010 09:57, "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx> wrote:
>
> >> The dummy data page should not be migrated because it has p2m type
> >> mmio_direct, which will fail the p2m_is_ram() check in mod_l1_entry() when
> >> dom0 attempts to map the page to save/migrate it.
> >
> > Ah, so it will; I hadn't seen that. The full failure mode is actually
> > on migrating from Xen 3.3 (where mod_l1_entry() didn't have that check)
> > to a newer Xen on a machine where the HW APIC virt isn't supported. The
> > sender sends the contents of the dummy page (incorrectly) and the
> > receiver doesn't do anything (assuming that there'll be a hole in the
> > p2m where the APIC should be).
>
> Well, even so, the patch would still appear to only clear the p2m entry if
> the APIC is disabled or relocated. Why would either be the case during
> save/migrate?
Eh, good point. But it also re-sets the mmio-dm p2m entry in the case
where the HW support _is_ available, which, now that I think of it,
would also be broken. :)
> Anyway, somewhat academic given we agree it's not needed at all in 3.4+
Well, forward compatibility for save files would be nice (and indeed is
needed in XenServer for live upgrade of a server pool to a new version)
but since 3.4 -> 4.0 works, I'm happy to let it go.
Cheers,
Tim.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home