Xen devel - May 2010 - [PATCH] VMX virtual-apic: Update the p2m mapping alongside the control bit

Otherwise a VM migrated from a system which supports the feature to one
which doesn''t ends up with a data page where its vlapic should be.

Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>




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

On 25/05/2010 15:42, "Tim Deegan" <Tim.Deegan@citrix.com> wrote:
> Otherwise a VM migrated from a system which supports the feature to one
> which doesn''t ends up with a data page where its vlapic should be.
I don''t see that this problem exists, let alone that this patch would
fix it
if it did.

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.

Even if that weren''t the case, the dummy page will be mapped into the
guest''s p2m unless the apic is disabled or relocated from its default
physaddr location. Neither of these is especially likely to be true during
save/migration.

The only thing I can see is this patch avoids a dummy page hanging around in
the p2m when HW APIC virt is disabled. But the dummy page is pretty benign
in this situation, so I don''t see that we care.

 -- Keir
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> 
> 


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

At 08:22 +0100 on 26 May (1274862163), Keir Fraser
wrote:
> On 25/05/2010 15:42, "Tim Deegan" <Tim.Deegan@citrix.com>
wrote:
> > Otherwise a VM migrated from a system which supports the feature to
one
> > which doesn''t ends up with a data page where its vlapic
should be.
> 
> I don''t see that this problem exists, let alone that this patch
would fix it
> if it did.
I''ve seen it happen, if that helps. :) 
> 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).

There might be a more correcter thing to do (maybe detect the RAM page
and explicitly free it back to Xen?).  Or, of course, we could finally
get round to explicitly registering all mmio_dm areas...

Sorry for the confusion - I''m trying to tidy up patches from our
product
patchqueue and some of them have been around for a while. :|

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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

On 26/05/2010 09:57, "Tim Deegan" <Tim.Deegan@eu.citrix.com>
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?

Anyway, somewhat academic given we agree it''s not needed at all in 3.4+

 -- Keir



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

At 10:46 +0100 on 26 May (1274870761), Keir Fraser
wrote:
> On 26/05/2010 09:57, "Tim Deegan"
<Tim.Deegan@eu.citrix.com> 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@citrix.com>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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