[Xen-devel] FW: FW: [PATCH 1/6] vTPM: event channel bind interdomain with para/hvm virtual machine

["Xu, Quan" <quan.xu@xxxxxxxxx>]

Forward to mail list. 
Thanks for your comment, I will read it in detail and try out some of your 
suggestions. 

Quan
> -----Original Message-----
> From: Daniel De Graaf [mailto:dgdegra@xxxxxxxxxxxxx]
> Sent: Friday, October 31, 2014 2:29 AM
> To: Xu, Quan
> Cc: samuel.thibault@xxxxxxxxxxxx
> Subject: Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> para/hvm virtual machine
> 
> On 10/30/2014 11:06 AM, Xu, Quan wrote:
> [...]
> >> +   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
> 
> This seems to preclude the use of stub domain device models for HVM domains;
> in that case, the event channel/grant page would need to be mapped to the stub
> domain.  I think it may be better to pass in the target domain ID in xenstore
> rather than overriding it based on PV vs HVM.  In any case, in order to 
> support
> HVM domains with PV drivers, an additional backend/frontend pair is required
> for QEMU rather than redirecting the existing vTPM to the device model's
> domain.
> 
> I would suggest attaching the vTPM directly to domain 0, but that would cause
> the vTPM to be picked up by the dom0 kernel instead of by QEMU, so that is not
> helpful.  If there is an existing solution for disk or network driver domains
> attached to HVM, the solution used there should be mirrored here; I have not
> looked to see how (or if) it is solved in those drivers.
> 
> A solution needs to be able to handle:
> 
> 1. Existing PV domains
> 2. HVM domain using TIS MMIO and no stubdom - without special casing dom0 3.
> HVM domain using TIS MMIO via a stubdom 4. Linux HVM domain with the PV
> vTPM driver (talks directly to the vTPM)
> 
> Similar to network and disk, when an OS that understands Xen devices finds a
> vTPM interface, it should detach/ignore the MMIO TPM interface.
> The vTPM domain is set up to handle this case: multiple connections to a 
> single
> vTPM domain are permitted and will all talk to the same TPM instance.  
> Locality
> restrictions are based on the event channel endpoint, and so will still work 
> even
> when tpmif->domid is incorrect; this is required to properly implement the 
> DRTM
> if it is to be emulated.
> 
> --
> Daniel De Graaf
> National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel