Stefan Berger
2006-Aug-25 21:33 UTC
[Xen-devel] [vTPM] Prevent domain with attached vTPM from doing local migration
The attached patch prevents a domain with an attached vTPM from doing local migration since this does not seem to work correctly (see tests in xm test suite). If no vTPM has been attached, the local migration proceeds as usual. Signed-off-by: Stefan Berger <stefanb@us.ibm.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor
2006-Sep-05 12:50 UTC
[Xen-devel] Re: [vTPM] Prevent domain with attached vTPM from doing local migration
On Fri, Aug 25, 2006 at 05:33:08PM -0400, Stefan Berger wrote:> The attached patch prevents a domain with an attached vTPM from doing > local migration since this does not seem to work correctly (see tests in > xm test suite). If no vTPM has been attached, the local migration > proceeds as usual. > > Signed-off-by: Stefan Berger <stefanb@us.ibm.com>I''ve applied this, thanks. Do you know what it would take to get localhost migration working for domains with a vTPM? Localhost migration is a useful test, and it seems a shame to break it in this case. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefan Berger
2006-Sep-05 13:19 UTC
Re: [Xen-devel] Re: [vTPM] Prevent domain with attached vTPM from doing local migration
xen-devel-bounces@lists.xensource.com wrote on 09/05/2006 08:50:49 AM:> On Fri, Aug 25, 2006 at 05:33:08PM -0400, Stefan Berger wrote: > > > The attached patch prevents a domain with an attached vTPM from doing > > local migration since this does not seem to work correctly (see testsin> > xm test suite). If no vTPM has been attached, the local migration > > proceeds as usual. > > > > Signed-off-by: Stefan Berger <stefanb@us.ibm.com> > > I''ve applied this, thanks. Do you know what it would take to getlocalhost> migration working for domains with a vTPM? Localhost migration is auseful> test, and it seems a shame to break it in this case.The vTPM needs to be able to handle the messages that are sent to it via the hotplug scripts either in-order or out-of-order, where in-order means that an equivalent of a ''close'' message comes before the ''open'' and out-of-order means that the ''open'' comes before the ''close''. From what I saw when I wrote and tested the vTPM hotplug scripts is that the messages sent from these scripts (kicked-off by the xenbus) can come in either one of these orders when doing local migration, probably due to timing. The vTPM also must not tear down its state when the ''close'' comes since a) the ''open'' might have come before it *and* b) one would have to re-initialize the vTPM. The reason for this is that a TPM keeps internal state, such as keys, that are created or loaded into it and that can normally be removed upon a ''close'' *if* that ''close'' always means power-off. Here (in Xen) it has to be treated differently, which boils down to ignoring the ''close'' since this can also be sent during a suspend. So the trick that I found was to handle things late in the ''open'' where I can determine whether a domain was ''created'' or ''resumed'' (after local migration or suspend/resume) and reset the device if necessary. Well, it''s a bit tricky intergrating the vTPM. Stefan> > Ewan. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel